Reflow - unclear requirement leads to wrong tests

[gundulaniemann]

When applying the SC 1.4.10 reflow, we experience a lot of disagreement on how it should be tested and which issues are violations looking at the normative text.
This leads to many discussions with customers and test agencies.

Issues:
A) The Success Criterion is unclear when reading the normative text, the intent, the understanding and the test instructions in the techniques.
Customers and test agencies test via zoom to 400%, even regulations established this method as test for Reflow (like BITV 2.0 test instructions, Germany).
It is not understood that the SC is about restricted dimensions and explicitly does not request a text enlargement by 400%. Also it is not understood, that 400% zoom is used in success techniques for verification, yet never in failure techniques to detect issues.

As a consequence:

• instead of restricting virtually one dimension, two dimensions are restricted at the same time, which leads to many more issues found.
• test is often performed on high-end monitors with a page ratio of 16:10 or 16:9 instead of 4:3, which leads to more and different issues being reported

B) The Success Criterion asks that the content can be presented in a width equivalent to 320 CSS px (in case of vertical scrolling content) without the need to scroll in two dimensions.
This way this AA-criterion exceeds SC 1.4.8 Visual Presentation Point 5, which is AAA. This is imbalanced.
Moreover, 1.4.8 talks about "while reading one line of text", which 1.4.10 asks to avoid scrolling in two dimension for the content, which is understood to be the page as a whole. So, also in this way the level AA SC goes beyond the Level AAA SC.

Therefore I ask to agree on one of the following changes (in the order of preference):

1. turn SC 1.4.10 to AAA to give balance to the WCAG as a whole, and to review the understanding document to give clarity
2. review the understanding document to make clear it is about restricting one dimension (which one depends on the reading direction) and eliminate all references to 400% zoom in the test instructions AND
   make clear that scrolling while perceiving a piece of information shall be avoided, not scrolling the whole page. For example, a content list can be perceived without horizontal scrolling, while scrolling the page is needed to consume the content. Again, consuming a specific line of text or a label-value pair shall not require scrolling in two dimensions, while scrolling might be needed to turn from one text column to the second, for example.
   The motivation clearly states that in fact this is intended, not avoiding scrolling of the whole page.
3. turn the applicability to consumption of pure text, exempting all sets of web pages which require interaction beyond navigation AND review the understanding document to give clarity

[bruce-usab]

@gundulaniemann changing the level is normative, so that does not seem possible. I want to think about your (3) because that looks like a normative change, but might be correct in actual practice (and so, not normative).

[mbgower]

Relevant discussions in:
#932
#2073

[JAWS-test]

#3377, #987, #3233 and many more (see search for 1.4.10) - this shows that there is a lot of uncertainty about 1.4.10 and a need to finally clarify it.

[JAWS-test]

I think that if we only test 320 px in 1.4.10 as required in the SC, then this has nothing to do with accessibility, but would be a pure usability requirement that does not belong in the WCAG. In WCAG, 1.4.10 is because of 400% zoom, as it is explained in the Intent of Understanding. That's why I think a test procedure with 400% at fixed height and width is correct, even if it's not in the SC like that.

I agreed with @gundulaniemann that the ban on two-dimensional scrolling should be limited to making it easier to read a section. If a page has to be scrolled two-dimensionally to get from text column 1 to 2, for example, I think that's hardly problematic.

However, all this cannot be changed afterwards, so I consider clarification, in whatever form, to be important.

[yatil]

I agreed with @gundulaniemann that the ban on two-dimensional scrolling should be limited to making it easier to read a section. If a page has to be scrolled two-dimensionally to get from text column 1 to 2, for example, I think that's hardly problematic.

This would be a testing and implementation nightmare. Good luck.

The requirement came from the low vision task force, explicitly addressing barriers that that community has. I think it’s problematic to invalidate the research and contributions of people directly affected by these SCs.

Functionally, a 320px wide viewport is the same as a 1280px wide one at 4x zoom. That’s how zoom works, including media queries that address this issue.

[gundulaniemann]

@yatil It is about clarity in the requirement and an overall comprehensive concept in the regulations.
Restricting the width is not equivalent to zoom, as zoom influences the display in two dimensions, not only in the width.
In addition, the understanding document explicitly states that s is not required that the text enlarges 400% while displaying the UI in the width equivalent to 320 CSS px.

[gundulaniemann]

@gundulaniemann changing the level is normative, so that does not seem possible. I want to think about your (3) because that looks like a normative change, but might be correct in actual practice (and so, not normative).

@bruce-usab Indeed the changes to 4.1.1 of parsing are also normative. So I still believe it is possible, as all User Interfaces complying with the old version still comply with the new version.

[gundulaniemann]

@JAWS-test Still there is a mismatch between the motivation (support 400% zoom) and the normative text and explanation. The normative text restricting restricts one dimension, the explanation states one option for compliance is providing a mobile version which is reachable from the web version (where by nature only one dimension is restricted), and another option for compliance is support of 400% zoom while the text enlarges by 200%.

[alastc]

Gundula wrote:

It is not understood that the SC is about restricted dimensions and explicitly does not request a text enlargement by 400%.

The understanding document says:

The relation of Reflow to the Success Criterion 1.4.4 Resize Text
The focus of the Reflow Success Criterion is to enable users to zoom in without having to scroll in two directions. Success Criterion 1.4.4 Resize Text also applies, so it should be possible to increase the size of all text to at least 200% while simultaneously meeting the reflow requirement.
...
In an implementation where text does not consistently increase its size as people zoom in (such as when it is transformed based on a media query to adapt to small-screen usage), it must still be possible to get to 200% enlargement in order to satisfy the Resize Text criterion.

How would you phrase that to clarify?

Gundula wrote:

The Success Criterion asks that the content can be presented in a width equivalent to 320 CSS px (in case of vertical scrolling content) without the need to scroll in two dimensions.
This way this AA-criterion exceeds SC 1.4.8 Visual Presentation Point 5, which is AAA. This is imbalanced.

Media queries did not exist when WCAG 2.0 was written, the technology allowed for for this improvement.

Gundula wrote:

turn SC 1.4.10 to AAA to give balance to the WCAG as a whole, and to review the understanding document to give clarity

That decision was made about 6 years ago with group and public / W3C consensus, so not really an option now.

Gundula wrote:

review the understanding document to make clear it is about restricting one dimension (which one depends on the reading direction) and eliminate all references to 400% zoom in the test instructions AND
make clear that scrolling while perceiving a piece of information shall be avoided, not scrolling the whole page.

Not scrolling the whole page is part of it though. Specific content can scroll horizontally within a vertically scrolling page (e.g. a data table that meets the exception), but the whole page shouldn't have horizontal scrolling.

We could potentially add an example such as a video streaming site where it has horizontally scrolling areas within a vertically scrolling page. If the horizontally scrolling areas are less than 256px tall, they would pass.

FYI, Reflow is the first target of the WCAG 2.x backlog task force, we're aiming to group the open issues on that together and tackle them first.

[JAWS-test]

It would be interesting to see to what extent 5.2.2 Full pages ("A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive Web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform") can be tested with WCAG 1.4.4. Assuming I have a device with the size 640 x 512 px and then test 200% zoom according to 1.4.4, I get a resulting size of 320 x 256 px and there should then apply: "without loss of content or functionality."
Then it wouldn't matter if 1.4.10 tests only height or width, because 1.4.4 together with 5.2.2 requires that 200% must be possible at all viewport sizes.

[melaniephilipp]

@yatil you said:

The requirement came from the low vision task force, explicitly addressing barriers that that community has. I find it astounding, but not surprising, that accessibility experts, who are not part of that group, want to define which barrier is problematic enough to be included.

Throughout the development of 1.4.10, the fundamental barrier that Wayne Dick emphasized strongly and presented research on (and the Understanding doc also emphasizes) is the need to pan the viewport from side to side to go from the end of one line of text to the beginning of the next when at a high zoom level. From what I can see in this discussion and the many others in this GitHub repo, no one is trying to dilute 1.4.10's solution to that fundamental barrier.

Understanding and application of this SC is all over the map (see all the Github issues). I regularly see things are failed in assessments that are not remotely the intent of the SC. I fully support unifying the collective understanding of what the fundamental barrier(s) being solved for are and clarifying what is and what is not a failure based on that.

[gundulaniemann]

Alastair wrote:

Gundula wrote:

It is not understood that the SC is about restricted dimensions and explicitly does not request a text enlargement by 400%.

The understanding document says:

The relation of Reflow to the Success Criterion 1.4.4 Resize Text
The focus of the Reflow Success Criterion is to enable users to zoom in without having to scroll in two directions. Success Criterion 1.4.4 Resize Text also applies, so it should be possible to increase the size of all text to at least 200% while simultaneously meeting the reflow requirement.
...
In an implementation where text does not consistently increase its size as people zoom in (such as when it is transformed based on a media query to adapt to small-screen usage), it must still be possible to get to 200% enlargement in order to satisfy the Resize Text criterion.

How would you phrase that to clarify?

In fact, this paragraph effectively results in that

• being able to display the page in 640 CSS px width is sufficient, if
• while reacting on zoom, a zoom further than 200% has no visible effect.
  If a user interface chooses to go this way, it usually results in a less enjoyable user experience. Therefore I understand 'In an implementation where' as an 'if' and not the recommended way to do it.
  As the Success Criterion does not focus zoom (it is not in the normative text) but intends zoom, I suggest to write:

"The intent of the Reflow Success criterion is to enable users to enlarge text without having to scroll in two dimensions while consuming a line of text. Success Criterion 1.4.4 Resize Text also applies, so it should be possible to increase the size of all text to at least 200% when zooming.
For most implementations [... as before ...]"

Alastair wrote:

Gundula wrote:

The Success Criterion asks that the content can be presented in a width equivalent to 320 CSS px (in case of vertical scrolling content) without the need to scroll in two dimensions.
This way this AA-criterion exceeds SC 1.4.8 Visual Presentation Point 5, which is AAA. This is imbalanced.

Media queries did not exist when WCAG 2.0 was written, the technology allowed for for this improvement.
In fact, that is not the point.
SC 1.4.8 Visual Presentation Point 5, which is AAA, effectively means that the page can be displayed on 640 CSS px width (and a height of 512 CSS px at the same time) without horizontal scrolling, if we assume a monitor size of at least 1280x1024 CSS px size shall be supported. This is independent of whether the page technically reacts to zoom or to effective window size.
SC 1.4.10 reflow, which is AA, says to display the page on 320 CSS px width without scrolling.
Specifically if the HTML page reacts the same way on zoom and window size (the old way), fulfilling 1.4.10 goes beyond 1.4.8.
So this is unbalanced.

Alastair wrote:

Gundula wrote:

turn SC 1.4.10 to AAA to give balance to the WCAG as a whole, and to review the understanding document to give clarity

That decision was made about 6 years ago with group and public / W3C consensus, so not really an option now.
In WCAG 2.2, we did realize updates to older decisions. It became necessary after evaluating how parsing is handled.
We also can revise old decisions with respect to the Reflow Success Criterion.

Alastair wrote:

Gundula wrote:

review the understanding document to make clear it is about restricting one dimension (which one depends on the reading direction) and eliminate all references to 400% zoom in the test instructions AND
make clear that scrolling while perceiving a piece of information shall be avoided, not scrolling the whole page.

Not scrolling the whole page is part of it though. Specific content can scroll horizontally within a vertically scrolling page (e.g. a data table that meets the exception), but the whole page shouldn't have horizontal scrolling.

We could potentially add an example such as a video streaming site where it has horizontally scrolling areas within a vertically scrolling page. If the horizontally scrolling areas are less than 256px tall, they would pass.

Why does a horizontally scrolling area within a vertically scrolling page need to restrict its height?
The Success Criterion does not state so.
This interpretation rather sounds like each piece of information (line of text, label-value pair, table cell, video, ...) needs to be displayed within 320 px width and 256 height (at the same time!) without having to scroll in two dimensions.
This connects to Option 2 which I suggested.

Alastair wrote:

FYI, Reflow is the first target of the WCAG 2.x backlog task force, we're aiming to group the open issues on that together and tackle them first.
Good to know, thank you.

[gundulaniemann]

It would be interesting to see to what extent 5.2.2 Full pages ("A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive Web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform") can be tested with WCAG 1.4.4. Assuming I have a device with the size 640 x 512 px and then test 200% zoom according to 1.4.4, I get a resulting size of 320 x 256 px and there should then apply: "without loss of content or functionality." Then it wouldn't matter if 1.4.10 tests only height or width, because 1.4.4 together with 5.2.2 requires that 200% must be possible at all viewport sizes.

The assumption is exactly the point.
If a UI is meant to run on a device with a 640x520px screen size, then the resulting with and height to be supported indeed is 320x256px by the need to support 200% text resizing.
(Well, not exactly, as only text needs to enlarge, not other elements.)
Even more, if the User Interface is intended to be run on a handheld like a smartphone, the resulting screen estate by text enlargement usually is smaller than 320 CSS px. (In many cases it comes close to 200 CSS px width, depending on the devices supported.)

But: many applications are not meant to be run on a handheld. They are meant for a desktop device. And the smallest monitor being in regular daily use is at least 1280x1024 px.
And then we have a conflict, as on one hand testing by zoom and testing by restricting dimensions do not yield the same results, and the AA requirement in fact exceeds the AAA requirement.

[yatil]

[Aside: I just edited a comment above that had language in it that came across more strongly and negative than I had intended. I have privately apologized, too, but I also want to apologize to the WCAG community. It was not called for and I regret content and tone of the statement.]

[yatil]

If a UI is meant to run on a device with a 640x520px screen size, then the resulting with and height to be supported indeed is 320x256px by the need to support 200% text resizing.

Text resizing does not change the viewport. And the 200% text size requirement allows for horizontal scrolling.

But: many applications are not meant to be run on a handheld. They are meant for a desktop device. And the smallest monitor being in regular daily use is at least 1280x1024 px.

Right, and a monitor at that size with 400% zoom has a viewport of 320px by 256px.

The two requirements are different, and they do not stack. For Text Resize, the reference point is whatever your current resolution is (= all resolutions). For Reflow, it is always 1280px at 4x Zoom/320px without text resizing. I blogged about this last year, too, as I just remembered.

That the default setting for text resizing is also zoom is a quirk of how browsers chose to implement text resizing, but many browsers allow changing the text size independently of zooming the viewport. The SC does not care which of the settings is used, as long as an increase to 200% can be achieved.

I’m all for making this SC more clear, but I also doubt we get there by changing the Understanding documents, which are non-normative. I am also strongly opposed to making an SC a AAA criterion that has been a AA criterion for many years, especially without a replacement that addresses the user need.

(Maybe this has been pure luck on my side, but I have not run into the circumstances that others have where it was impossible to meet 1.4.10 Reflow. Sometimes there was some more elaborate designing and coding involved, sometimes I might have used the exception slightly generously. But there was always a way, often by looking at and getting inspired by mobile applications that often do similar functionality on small screens.)

[gundulaniemann]

@yatil Can you give some examples of such pages?

[NickBromley]

@yatil

That the default setting for text resizing is also zoom is a quirk of how browsers choose to implement text resizing, but many browsers allow changing the text size independently of zooming the viewport. The SC does not care which of the settings is used, as long as an increase to 200% can be achieved.

How would you handle a page where text-only resize to 200% results in content overlap, whereas full page zoom to 200% does not result in content overlap? Is it:

• a fail, because the method of zooming that does not work is the method that is arguably the one closest to the normative wording of the SC?
• a pass, because at least one method of zooming works?

You could make a justifiable case for each one and yet neither feels like a satisfactory result.

[patrickhlauke]

• a pass, because at least one method of zooming works?

This has been the accepted way - certainly in the companies I worked/am working at, and anecdotally at all other companies doing assessments where I know people - of dealing with this.

[alastc]

Why does a horizontally scrolling area within a vertically scrolling page need to restrict its height?

So that you don't have the 2-directional scrolling problem, which applies to reading and navigation (as it says at the bottom of the intent section).

For example, take a page with 3 or 4 columns, and imagine it didn't reflow:

The red box is about 320 by 256. Image scrolling that left and right to try and work out what is there. It is essentially the kind of issues you get when having a magnified view that does not adjust (reflow) the layout.

On the other hand, if you have a small section of horizontally scrolling content like the date and cost bar here:

Or even a set of short horizontally scrolling items like a video selection page:

This doesn't make it difficult to navigate, and you aren't at risk of missing things.

If a UI is meant to run on a device with a 640x520px screen size...

The intent is to make the interface flexible (with compromises to make testing practical). That could be a device at 640 wide, or more likely a standard monitor with the resolution reduced. It doesn’t really help to talk about devices in this context, it is about setting a reasonable level of flexibility.

Another point to consider is that increasing text-size uniformly over 200% often has negative impacts. Although the LVTF would have loved to get 1000% as a maximum increase, you have to reduce the size-differences between text when you go over 200%. E.g. a main heading that starts at 40px could be 3 or 4 times bigger than the body text. The text which is large to start with could be un-managably large at 400%.

That is why reflow does not require text to follow that increase, and is a separate requirement from text-sizing.

[gundulaniemann]

Alastair, thank you for the explanation.
Unfortunately, I still don't understand your point.

In the first example, each text in the first column can be read without scrolling in reading direction. This is regardless of the text length, that is, the height of the text block.
The second column is too wide, so the user needs to scroll in reading direction while perceiving the text.
There is no horizontally scrolling content, the whole page scrolls in two directions, and columns are even too wide to accommodate to 320 CSS px width.
I understand you argue that it is a hassle to find the content at all, is that correct?

In the examples 2 and 3 there is content nicely scrolling horizontally in a carousel. Yet the ease of navigation does not stem from the restricted carousel height but from the way the content is organized. It is predictable where the content is.