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.