Closed allanj-uaag closed 7 years ago
Hello All,
In our presentation at CSUN on LVTF work we re framed linearization as follows: Everyone with low vision has tunnel vision on the web: Either they have the medical condition and need a narrow view or they have impaired visual acuity and enlargement creates limited view.
The result is that everyone with low vision needs, "a sequence of single purpose windows," so that they can reliably find all important information on the sight and / or enlarge sufficiently with word wrapping to perceive the information.
The need is : A sequence of single purpose windows. Linearization to a single column is one way to do this.
Alan Cooper would refer to this as a sequence of sovereign postures.
For people who are running a normal web page, the ability to support responsive design is enough. For these pages a simple script would test the page.
What is certain is that this is the one SC that is needed by 100% of people with low vision, and it is essential.
WCAG WG based its strategy for low vision on three incorrect hypotheses:
1) Enlargement without word wrapping is accessibility support 2) 200% is sufficient enlargement for anyone who is classified as having low vision because of reduced visual acuity 3) More contrast is better
Before we start to pick apart the SCs one by one, I think it is time to absorb impact of basing an accessibility strategy on fallacy. It means that we may need to ask developers to go back and do extra work we did not ask the first time around.
We need new foundations: The following are necessary:
1) Enlargement of all text with word wrapping. 2) Access to a sequence of sovereign windows. 3) Ability to override visual style for text.
These have been established as minimal necessities. It is time to figure out how to do it. We need to take a deep breath and ask developers to do what is needed, after doing our best to determine exactly what that is.
Hi Wayne, I'm not clear what the 'fallacy' is you are referring to?
ask developers to do what is needed, after doing our best to determine exactly what that is.
Indeed.
The main problems I see with this generally good idea are: 1) Clarity - where do we draw the line with what does and does not need to reflow? I think that it is clear that an image that is wider than the screen wouldn't need to magically wrap (and how would it?) but tables are a big topic in the discussion, and there are other structure types that we need to feel confident that we aren't causing problems for. 2) Implementability - this is going to limit the acceptable development strategies for regular content, and on top of that there are questions about the support for this in mobile browsers and in mobile apps - how achievable is this today?
Elements which cannot reflow such as image can still 'fit', it is easy to use something like img { max-width:100%;}
like this test page, as an author or user-script.
Tables are the only group-container that is 2D and contains text. I suggest we rely on 1.3.1 for requiring a data-table for data, and say that they are exempt (under the 'spatial layout') but that layout tables should be linearisable.
The user-side script I started with included:
// Wrap data tables in a div that allows for horizontal scrolling
var dataTables = $('table:has(th)');
$(dataTables).wrapAll( "<div style='width: 100%; overflow:auto; outline:3px grey solid;padding:3px' />");
// Reflow presentational tables
var layoutTableCells = $('table[role=presentation] td');
$(layoutTableCells).css('display', 'block');
That could be more robust and elegant, but it worked as a starting point.
I can't think of anything else that isn't either a text element that linearises easily, or an image/svg/object type thing that would be exempt?
For Implementability, arguably it isn't asking for more that 1.3.1, except that SC (crucially) hasn't been interpreted as making sure the user could linearise the page. The initial test-script works pretty well on quite a few sites, e.g. BBC, Wikipedia, Microsoft. Any responsive site starts from a linearised point of view so that is fairly easy, but there methods that people use that really disrupt user-driven linearisation.
The things that are currently difficult tend to be the really aggressive layouts, where scripting is used to position things (or we haven't found the right CSS to nullify the layout yet).
For mobile, arguably some devices have that built in already (with the Reader view in Safari for example), but no-one tests against that and the rules/heuristics behind it are a mystery. You can use bookmarklets (like the example) on mobile, so it is possible.
You are going to need to allow aria grids and treegrids not to wrap too [role=grid] , [role=treegrid]
Yep, presumably at the same level, so exempt anything within that block.
Noting another comment about the mechanism language:
this requirement sounds like it's asking for websites to place a "linearize" button on the page.
@alastc Could people who needed content linearised or single-column formatted - like this, not have a plug in etc that did this? So the dev has to code things in a way that just facilitates this functionality? That to me is reasonable, rather then the dev themselves having to have a 'mechanism'?
@joshueoconnor Yep, that's the primary aim. It is in the same category (in customisation levels) as adapting text - let the user do it. Maybe we can import the note from adapting text.
@alastc Sounds good to me :-)
Trying to get grip on this SC here some small remarks:
At “Relevant Guidelines and Success Criteria” I’m wondering if guideline 1.3 will be renamed as I see “Guideline 1.3 (Flexible Date) is essential for reflow.” I didn’t think 2.0 text would be changed and the current name is “Adaptable”.
textual corrections: “Flexible Date” should be “Flexible Data” and “(Meaningful Sequences)” should be “(Meaningful Sequence)”
About raising the level of SC 1.4.8(2) to Level A: I do understand there is a relation between 1.4.8(2) and Reflow to Single Column but restricting column size seems not appropriate. It could be that I do want to make a very wide column with big text for a web application shown on a large screen. So I’m wondering if 1.4.8(2) is relevant here as restricting to 80 characters for a Level A seems too strict.
The most appropriate location to me seems Principle 1, Guideline 1.3 (Adaptable) and not as suggested Principle 1, Guideline 1.4 (Distinguishable). This because 1.3 is about “Create content that can be presented in different ways (for example simpler layout) without losing information or structure.” Especially if we expect user to linearize content themselves. Guideline 1.4 is concerned with making the default presentation as easy to perceive as possible although I realize SC 1.4.4 Resize Text sits in 1.4.
Extending on this (Adaptable) I see we need to fix the concerns as Leonie mentioned when she brings on a valid issue when tables are used for layout: https://github.com/w3c/wcag21/issues/58#issuecomment-273804060 This must be addressed.
And also Fiona has a point https://github.com/w3c/wcag21/issues/58#issuecomment-284159623 for show/hide content and turning off CSS but this is inherent if we take the comment of Alastair into account at: https://github.com/w3c/wcag21/issues/58#issuecomment-273935955 nr.2
So when Linearization is about adaptable content as Alastair says “but to make sure that if someone does forcibly reflow the content, the reading order makes sense.” It seems to me the content author only needs to be sure there is meaningful sequence in the DOM for web (HTML) .
The suggestion that reflow if covered by SC 1.3.2. seems valid especially when reading the text in the thread https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JanMar/0202.html “2. Reflow to single column [2] is to enable people to go beyond 400% and have a correct reading order. It is NOT intended to be the authors responsibility to make the reflow happen (in HMTL), but to make sure that if someone does forcibly reflow the content, the reading order makes sense.”
In SC 1.3.2 we also have “For clarity: Providing a particular linear order is only required where it affects meaning.” And this covers linearization, not?
As Wayne already says in https://github.com/w3c/wcag21/issues/58#issuecomment-277046105 “We can already produce a linearized accessibility API. Why is that so difficult in the browser?” isn’t this already true in the case of the DOM which must have a meaningful sequence (SC 1.3.2) and thus fits the condition for linearization?
As John says https://github.com/w3c/wcag21/issues/58#issuecomment-273231053 “Tables can be linearized today“ and Alastair at https://github.com/w3c/wcag21/issues/58#issuecomment-273935955 and https://github.com/w3c/wcag21/issues/58#issuecomment-287919785 this is true from a CSS perspective if this is what you mean but not from an accessibility perspective as playing with the display property for a table removes the role from the accessibility API and causing screen readers to not recognize them as tables anymore. This means if you’re zoomed in and using a screen reader the tables are not read properly anymore. Also using the arrow keys cause strange behaviour skipping / jumping around.
For “A mechanism is available to view content…” I wonder if this is something a content author should / could provide or that it is a function of a user / user agent for instance and I see this was also mentioned by Paul and referenced by Alastair: https://github.com/w3c/wcag21/issues/58#issuecomment-288461497. And Jared at https://github.com/w3c/wcag21/issues/249 Seems like we’re steering at making it possible for users to do the linearization themselves and not providing a mechanism (to be available).
The difference between "“A mechanism is available” and "“A mechanism is provided” is that
with “A mechanism is available” — the author can rely on the mechanism being provided on the other end and they just need to support it.
With the “A mechanism is provided” - the author would need to provide it.
This should be clear from the Understanding WCAG 2.0 document — and if it is not - it needs to be added so that it is clear.
g
On May 5, 2017, at 6:04 AM, Jake Abma notifications@github.com wrote:
For “A mechanism is available to view content…” I wonder if this is something a content author should / could provide or that it is a function of a user / user agent for instance and I see this was also mentioned by Paul and referenced by Alastair: #58 (comment) https://github.com/w3c/wcag21/issues/58#issuecomment-288461497. And Jared at #249 https://github.com/w3c/wcag21/issues/249 Seems like we’re steering at making it possible for users to do the linearization themselves and not providing a mechanism (to be available).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-299428008, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3psFnMi_3XbuMKVuQpVJf8Pwz-IBks5r2vQmgaJpZM4K-ARo.
Comment on linearization. I've accommodated and trained employees with low vision in banks and government for about 15 years. My experience is that once we need more than 400% (4x zoom), we are really into screen reader territory. I generally say "OK lets start thinking about migrating to learning a screen reader."
Almost all users I've worked at were extremely relieved to transition to screen reader at anything over 400%. One employee was nervouse to go to screen reader and hung onto zooming til it was 20x. (about 5 letters on a 27"screen) When we finally went to screen reader she was extremely relieved and wish she had done it sooner.
I don't think WCAG 2.1 should try to accommodate more than 400% without assistive technology. I think the ask upon the developer is disproportionate to the benefit to most end users.
I think after 400% the end user either needs AT like ZoomText's docreader app which reflows content, a screen reader, or other other means. I don't think it should be the author's responsibility at this point in history.
+1 to @DavidMacDonald
My experience is that once we need more than 400% (4x zoom), we are really into screen reader territory
Perhaps that is because there haven't been any good intermediate options? (I think Wayne and others would say magnification isn't a good option, at least for reading.)
I don't think WCAG 2.1 should try to accommodate more than 400% without assistive technology.
Do we consider user-side scripts/extensions AT? It is adapting the interface in a way that the author doesn't specify, so I would have thought so.
An important point about this SC is that we don't expect the author to provide a different interface, we expect them not to prevent the user making one.
I think that also in this case a note should be added, that the WG is seeking input on PDF.
I think you mean that for #77?
@alastc Also for this SC cause a PDF reflow is explicitly mentioned.
ok, I just meant this one hasn't gotten as far along yet, I don't think it is up for a CFC yet.
(I think Wayne and others would say magnification isn't a good option, at least for reading.)
The docreader pulls out the content and reflows it and does anything with the text the user wants. It's not perfect. It can be heavy on the system, and doesn't pull put controls etc... But I'll stand by my experience with many low vision employees. More than 400% is getting into screen reader territory, and it's a huge ask on developers in today's wild west environment.
https://www.youtube.com/watch?v=6cbYmbeDZyQ See at around 2:30.
Hi David,
The idea of this SC is to make something like ZoomText's docreader for the web work.
So this:
Becomes this (or something like it, the colours and size would be down to preference):
Simply by running a user-side script (that's a real example using bookmarklets).
As I've said above the mechanism is fairly straightforward, the things devs would have to worry about are mixing in layout with JS, and checking that dynamic updates to layout work when the layout has been neutralised.
Last time I checked the ZT doc read in PDF (Acrobat) it appeared that i was copying the content from the page using something like the clipboard and inserting it into the doc reader. I could be wrong and maybe on the web it is more complex than that.
According to their video the DocReader is for Word/PDF, and it does pull the text into a separate window. (AppReader they suggest for web content, but that reads it out audibly whilst highlighting the location, it doesn't try and re-format the text.)
According to their video the DocReader is for Word/PDF, Doc Reader is for HTML also.
Current versions of SC and Definitions
SC for viewing | SC for editing
SC in full draft guideline ## Current versions of SC and Definitions
Understanding doc for viewing | Understanding doc for editing | Understanding doc in master
Open issues and Surveys
Open issues: SC Status page
(Links to surveys require W3C Member access)
SC Shortname
Linearization
SC Text
A mechanism is available to view content as a single column, except for parts of the content where the spatial layout is essential to the function and understanding of the content.
Suggested Priority Level
Level A
Related Glossary additions or changes
none
Relevant Guidelines and Success Criteria
Guideline 1.3 (Flexible Date) is essential for reflow. SC 1.3.2 (Meaningful Sequences) establishes the necessary structure for reflow to occur. Without reflow SC 1.4.4 (Resize Text) could not be extended to enable very large text. Finally, without reflow restriction of column size would be difficult. This allows raising the level of SC 1.4.8(2) (Visual Presentation (width)) to Level A.
Principle 1, Guideline 1.4 (Distinguishable) is the most appropriate location for this new success criteria. This is because it focuses on presentation of content in a single column of elements with all text in single column format.
The final fit for reflow is in Principle 2, Guideline 2.4 (Navigation). Most people with low vision could benefit from a single column view of a page. This is because items get lost in a two dimensional presentation. (See Benefits below)
Description
Content can be viewed in a single column. All text is presented in single column format and the Line Length SC ensures that all lines of text word wrap to fit the available space. Data tables will have a standard tabular display, a two-dimensional matrix. Some user agents do not support active data such as form controls in reflow. In these cases the content author is not responsible for creating content that reflows.
This good reflow of HTML was accomplished by a custom style sheet.
Properly reflowed PDF text.
Improper characters used by the author for spaces. This causes words to jam together with reflow. This authoring problem occurs frequently with PDF.
Benefits
One important need of most people with low vision is to reconfigure a presentation from a normal two-dimensional page to a one-dimensional organization of data. This is not always the case, but it is a frequent need. For quick scanning the original structure may be useful to scan for recognizable items. This is usually done when the user knows a page and is looking for just one thing. In cases where careful examination of the page is necessary one column presentation is needed. The reasons are given below.
Testability
Techniques
Existing Relevant Techniques
New Techniques
Note: This is necessary because non-decorative images cannot be reflowed.
Related Information
Articles
Email
GitHub
Minutes
Surveys
Wiki Pages