Issue 58 linearization (was reflow)

[DavidMacDonald]

Added right before "resize text" See issue #58 for live links to these resources and a lively discussion that is both there and on a messed up pull request #89 which this replaces.

SC Short title

Linearisation

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.

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.

Reflowed HTML

This good reflow of HTML was accomplished by a custom style sheet.

Below is an improperly reflowed PDF text. bad PDF reflow

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.

1. Continuous Reading: Many people, with and without disabilities, find it more difficult to read when they must scroll from the bottom of a column of text to the top of another column. With low vision the need is greater. To go from one column to next frequently requires paging up several screens to get from the bottom of one column to the top of the next. Additionally, using a small scrollbar and cursor is difficult with limited sight. This makes getting from the bottom of a column and finding the top of the next column more difficult. Reading flow degrades and comprehension suffers.
2. Reliable Searching: (visual navigation of the viewport) Searching for a specific item within a page of information is difficult for almost everyone with low vision. This is because the field of vision is limited either by enlargement requirements, or physical visual field loss due to tunnel vision. The ability to only scroll in one dimension vertical only or horizontal only but not two dimensions, dramatically simplifies this problem. A person can start at the top of the page and move element by element down the page until the bottom, and be certain that every item has been scanned. (TSBVI,Specific Eye Conditions, Corresponding Impact on Vision, And Related Educational Considerations)
3. Resizing Text on a Large Scale: Two column or more do not support large print text. Even if text stays within column boundaries, multi-column format will not provide enough space for text in large print. Even medium length words will not fit for sizes exceeding 250%. This causes excessive hyphenation and becomes distracting. This criterion is a necessary condition for useful text resize criterion for people with visual acuity worse than 20/70. Many people in this range require print size greater than 1/2 in. (1 cm.). This cannot be sustained with standard formats. content.

User Need: Users can set blocks of text in one continuous block, instead of in multiple columns.

Source: Accessibility Requirements for People with Low Vision, Section 3.2.2

Testability

1. HTML: Use the Easy Checks - A First Review of Web Accessibility document, Basic Structure check. Check that the sequence of text is in fact a correct reading sequence. Note: These tests remove all style. This means that items that the author did not intend to be seen become visible. It can be useful to display the pages side by side to compare what is intended to be visible and what is not. If this test passes the content can be restructured into an accessible format for low vision using CSS and JavaScript.
2. PDF: With a user agent that enables reflow, use the reflow option to see content reflowed into one column. No lines should be truncated. If this operation is successful the document passes.

Techniques

Existing Relevant Techniques

• G57: Ordering the content in a meaningful sequence (Note: Correct Reading Sequence and meaningful sequence are the same in this context.)
• F1: Failure of Success Criterion 1.3.2 due to changing the meaning of content by positioning information with CSS

New Techniques

1. HTML: Write content so that the source order of perceivable elements defines a correct reading sequence. It is perfectly appropriate to include items that are not displayed to users in any convenient order. Such elements do not disrupt the correct reading sequence of the entire page. Make sure that elements that are not to be perceived are marked in a standard way like "display: none" or "visibility: hidden" so they can be ignored by a reformatting program. Test your document with no style in your user agent(s). See that it makes sense as a page and is fully operable. After this content is arranged and tested, positioning and other block formatting of the page. Use style sheets for positioning so that it can be removed and the resulting view is readable and operable.
2. HTML: Use media queries based on em units for reflow to single column. Reason: When the line length shrinks below a certain number of characters, reflow to a single column is triggered whether the reduced character count is caused by shortened lines or increased font size. This makes the reflow to single column accessible on more devices.
3. Fxx: Text becomes unreadable because of reflow.
4. Fxx: Failure of Success Criteria Text Colors and Reflow to Single Column due to inserting important information by using the background-image property of CSS.
   Note: This is necessary because non-decorative images cannot be reflowed.

Related Information

Articles

• HTML Source Order vs CSS Display Order - Adrian Roselli

Email

• Reflow is ready, and so is Line length - Wayne Dick, 15 November 2016
• Terminology Question (LVTF thread) Wayne Dick, 1 November 2016
• Latest Reflow - Wayne Dick, 31 October 2016
• Reflow test case (Thread) - Alastair Campbell, 23 October 2016
• Reflow Final Draft Wayne Dick, 4 October 2016
• Reflow LVTF Thread 30 September 2016
• I have made changes to Line Length and Reflow to Single Column - Wayne Dick, 20 August 2016
• Requirements doc - Alastair Campbell, 18 February 2016

GitHub

• Reflow to Single Column - WCAG 1.4.8 item 5 or New item LVTF GitHub SC Issue #7

Minutes

• 17 November 2016 LVTF Minutes
• 27 October 2016 LVTF Minutes
• 20 October 2016 LVTF Minutes
• 13 October 2016 LVTF Minutes
• 06 October 2016 LVTF Minutes (Informal Meeting)
• 29 September 2016 LVTF Minutes
• 4 May 2016 LVTF minutes

Surveys

• Survey items for October 20 LVTF meeting

Wiki Pages

[awkawk]

Related to #58

[IanPouncey]

This feedback is based on a collective review by @stevefaulkner, @patrickhlauke,
@IanPouncey, @jspellman and @LJWatson

Our feeling is that this should primarily be handled by user agents. In most cases, rather than actively supporting this, developers need to not prevent the functionality built into user agents.

However, it still remains true that common and valid development techniques will be made invalid by this SC. For example, any site that applies a fixed width to a container element will potentially fail, and this includes sites such Google, Yahoo!, Facebook, and Twitter, to name but a few.

A better outcome can be achieved with better tools. Safari's Reader view can linearize content, but currently only in certain circumstances, and often by losing content or design elements. If user agents added or improved modes of reflowing content the purpose of the SC could be achieved much more effectively.

We see a few options open here:

1. Drop the SC, and encourage user agents and tools such as Safari Reader to improve the way they reflow or linearize content.
2. Continue with the SC, but put more work into defining exact tests that sites are expected to pass. While techniques are useful, the number of ways that this SC can be failed with common development practices means that they can only provide partial coverage.
3. Push this SC to Silver; it seems like a potentially large change to make in a point update to WCAG.

[alastc]

HI @IanPouncey, did you see my reply to your previous comments?

For example:

For example, any site that applies a fixed width to a container element will potentially fail,

Not true, they would only fail if they prevented the user from applying a stylesheet/script/extension that linearises the page.

Also, it is worth seeing my outline of the process between FPWD and final 2.1.

That is essentially option 2 in your list. The intent is to push slightly but realistically on what authors need to do to support a user-agent tool. The Safari reader mode is one example, but the need is more akin to the 'linearise' in the webdev toolbar.

An initial bookmarklet script is here, the plan is to test that across many sites, improve the user-agent side (the script) until we hit brick walls that have to be done on the author side. Those become technique/failures.

[Ryladog]

Alistair, your idea and script is awesome!!!!!!!

[awkawk]

closed by accident. We need to change the base branch for this from FPWD to Master (my error David, I gave you a bad steer).

[alastc]

Regarding the comments on the 7th Feb survey, perhaps we should take the same approach as the override text one?

I.e:

No loss of content or functionality on a webpage is caused by overriding the layout to view as a single column, except for parts of the content where the spatial layout is essential to the function and understanding of the content.

I think that addresses comments from @patrickhlauke @joshueoconnor and Jeanne. I think Kim might need to read back on some of the previous github comments?

[IanPouncey]

This feedback is based on a collective review by @stevefaulkner, @patrickhlauke,
@IanPouncey, @jspellman and @LJWatson.

@alastc wrote:

"Not true, they would only fail if they prevented the user from applying a stylesheet/script/extension that linearises the page."

It isn't clear to us what an author could do (or not do) that would prevent a third party script or tool from reflowing the content? It's possible to do more or less anything with a third party script: rework and linearise the markup, drop or modify styles etc.

Even if a list of things authors must do (or not do) is identified now, the risk of it becoming out of date is considerable. We then risk constraining developers to behaviour circa 2017, when the web is more than likely to be a somewhat different thing in the future.

An implication of this SC seems to be that a third party tool/script is an acceptable solution? If that's the case, what incentive does an author have not to off-load responsibility onto the tool or script.

Taking that to its logical conclusion, many SCs could be solved with third party tools and scripts if someone were so inclined to create them. Where should the line be drawn?

[patrickhlauke]

Summarising a lengthy discussion with @alastc that happened outside of this...on the topic of reliance on extensions/scripts or application of custom styles and how these can't be determining factors for what authors can/can't/should/shouldn't do.

@patrickhlauke

[a bookmarklet or extension] can't be the only authoritative script though. [...] if your [bookmarklet/extension] is flawed/doesn't change things enough on certain pages, then it's the flaw of the [bookmarklet/extension], not the author. [otherwise it would make the bookmarklet/extension] the defacto validator for what authors do, and that seems rather short-sighted

@alastc

No, I want to use it to work out what the limits are. It is a means to get to techniques.

[...]

@alastc

I've tried over-riding sites layouts, and either you show too much, or get lots of overlapping. There is author responsiblity there.

@patrickhlauke

then it's YOUR overrides that are at fault. drop all author-defined styles in the worst case.

@alastc

I don't think that works. For example, anything with display:none gets shown, which then means the order & content are wrong. It is more complex than that.

@patrickhlauke

then make your script smart by analysing existing styles and keeping display:none for elements that have display:none now, etc. the fact that this is complex to do should not be the concern of the author. unless you want to start saying "authors should not use display:none because once a UA strips out those styles content that shouldn't be there becomes visible", which is of course an unrealistic author requirement

@alastc

There is a lot of grey area in the middle there, the display:none is just the start, the obvious issue. When [users] hit issues their extensions cannot overcome due to the way certain sites have been put together (e.g. site scripting that puts the carousel over the main content area), we've lost this avenue.

@patrickhlauke

if you can clearly demonstrate that this "way certain sites have been put together" is something completely outside of the possibility for a script/extension to cope with, and it can be traced back to a very specific html/css/js use pattern, and you can provide for each of these cases an alternative for authors to use that does not have these problems, then fine. and if there ARE better ways for an author to do things, demonstrate that the script/extension can't modify the current page on the fly to apply this better way. but this is a sisyphean tasks in my view and you'll keep chasing your tail of "is this particular thing fundamentally non-linearisable by a script/user style? or is it just that the current approach taken in th extension/script is incomplete?"

[alastc]

if you can clearly demonstrate that this "way certain sites have been put together" is something completely outside of the possibility for a script/extension to cope with, and it can be traced back to a very specific html/css/js use pattern, and you can provide for each of these cases an alternative for authors to use that does not have these problems, then fine.

That is the intended approach.

but this is a sisyphean tasks in my view and you'll keep chasing your tail of "is this particular thing fundamentally non-linearisable by a script/user style? or is it just that the current approach taken in the extension/script is incomplete?

It is a big task, but there will be several people involved (so far, more welcome!). If we go through the process and it turns into many dead ends (or OTOH if there is a simple solution on the UA end), then we drop it. I don't think that's the case though.

[patrickhlauke]

also don't forget this part

and if there ARE better ways for an author to do things, demonstrate that the script/extension can't modify the current page on the fly to apply this better way.

my concern here is that this will require potentially very high skill level. if the group determines that something "can't be done", how sure can we be that that's indeed the case, or simply down to a limited experience/skill/knowledge of people working on the extension/script?

It is a big task, but there will be several people involved (so far, more welcome!). If we go through the process and it turns into many dead ends (or OTOH if there is a simple solution on the UA end), then we drop it

are you confident this will be achievable within the timeframe of WCAG 2.1 publication?

[alastc]

my concern here is that this will require potentially potentially very high skill level. if the group determines that something "can't be done", how sure can we be that that's indeed the case, or simply down to a limited experience/skill/knowledge of people working on the extension/script?

We can do it in the open (e.g. bugs on the scripts), with live examples, and I'll be calling on some of our devs, and putting these things up for review by others, and blog/tweet about it.

are you confident this will be achievable within the timeframe of WCAG 2.1 publication?

I'm happy to do the testing, to get others involved (and Wayne has at least one comp-sci student to help), to keep it open, to come up with techniques and failures, and if they aren't clear enough / good enough, the SC can be deferred or dropped (or the techniques can be added to 1.3.1).

However, without an SC there doesn't seem to be any point in trying...

[awkawk]

merged to FPWD_review

[WayneEDick]

Linearization is the most important need of low vision. It is one point that is a need for almost everyone.

The problem is this. Everyone with low vision has tunnel vision. It is either the medical form or it is induced by the need for enlargement. This makes two dimensional searching extremely error prone. The result is that a sequence of single purpose windows that exhaust the content is the only organization that ensures successful use of content. The person with medical tunnel vision will use a narrow column of normal text, and the person with large print induced tunnel vision will view a sequence of enlarged content as full-screens. Multi-window, multi-column interfaces are simply intractable to all low vision, not some, all.

For people with visual acuity loss, single linear sequence also makes issues of text spacing and size irrelevant. The browser becomes the enlargement / word wrap engine. Since the quality of browser display is higher than any magnification can achieve, the browser is the place enlargement should take place.

Right now in 2017 we still have the ability to call out this property of well written HTML / CSS / Javascript. If we proceed much further in development of coding technique we may loose the opportunity to preserve this ability. A page that really satisfies SC 1.3.2 (Meaningful Sequence) should support CSS or Javascript that could linearize. In fact,

F49: Failure of Success Criterion 1.3.2 due to using an HTML layout table that does not make sense when linearized

F1: Failure of Success Criterion 1.3.2 due to changing the meaning of content by positioning information with CSS

pretty much ensure linearization is possible, and really should be achieved with user CSS. But, as we know it doesn't happen with many pages. Why?

We don't know all the reasons yet, but we can find many.

Responsive sites are easy to linearize completely. Often, responsive sites have fixed position elements that sit on top of meaningful content with enlargement. That is an author issue. It's not too much to ask authors to add the ability to toggle fixed position elements.

So, I don't see a problem with planting a stake here in 2017 that says don't lose this capability as you invent new technology. Otherwise it will be lost because only people with low vision know that linearization is necessary.