Feedback from Microsoft on wcag2ict Reflow notes 5 and 7

[scottaohara]

Based on our shared understanding at Microsoft for the intent of Reflow, and our interpretation of how WCAG2ICT is implying Reflow be considered for non-web software, we have concerns with two of the notes in the latest editor's draft. Each note, concern, and an initial proposal in how we feel the wording of these notes can be modified to help with our concerns are as follow:

(each proposed edit is bolded and enclosed in parenthesis to help identify differences from the current text)

Note 5:

The intent section refers to the ability for content to reflow when user agent zooming is used to scale content or when the viewport changes in width. For non-web software, this means that when users scale content, adjust the size of a window or dialog, or change the screen resolution, the content will reflow without loss of information or functionality, and without requiring scrolling in two dimensions; or that the application works with platform features to meet this success criterion.

Concern:

The note does not mention the normative sizing requirements (e.g., 320 width, 256 height), which currently reads to us as potentially reinterpreting the Reflow SC to go beyond the specified normative requirements. E.g., any resizing or scaling content should not produce bi-directional scrolling.

Proposal:

The intent section refers to the ability for content to reflow (up to 320px wide for vertical scrolling content or 256px tall for horizontal scrolling content) when a user agent zooming is used to scale content or when the viewport changes in (size). For non-web software, this means that when users scale content, adjust the size of a window or dialog, or change the screen resolution, the content will reflow meeting the normative requirement without loss of information or functionality, and without requiring scrolling in two dimensions; or that the application works with platform features to meet this success criterion.

Note 7:

As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 256 CSS pixels for horizontal scrolling content.

When the underlying user agent or platform does not support these dimensions for scrolling, reflow is encouraged as this capability is important to persons with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies.

Concerns:

We believe there needs to be an addition to this note that acknowledges the challenges of meeting reflow in non-web software given that the only way to resize content in many software applications is at the system level. With the number of exceptions on Reflow, it doesn’t seem practical for the user to have to resize the system at the OS level for certain apps and then re-size again for others (where the exceptions apply).

The underlying intent of the reflow rule was to make it easier for users to be able to read text content without having to scroll in multiple directions, reducing the level of effort of tracking between lines, and the physical effort needed for scrolling, not requiring a viewport size of 320x256px across all UI elements in all apps and OS.

This is relevant for non-web content applications and OS, because there isn’t generally a way to zoom in all the content of a specific app (where in this case, content refers to both the UI of the application AND the long form content (text/graphics)); instead, users need to use OS level settings to change the display and zoom level on all applications and the OS UI itself.

Some native applications DO allow for zooming in specific areas where users might be typing or reading (for instance an email software to compose mails / read mail content), but the rest of the UI doesn't adjust and would need to have adjustments at the OS level to make the content larger. This behavior should be sufficient to meet the spirit of the S.C. making reading text content easier.

Proposed changes to Note 7:

As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 256 CSS pixels for horizontal scrolling content.

(When attempting to reflow applications requires users modify zooming, scaling and/or display resolution changes at the OS level, it will impact the size of all other applications and the OS itself. This can result in problematic user experiences for applications where Reflow exceptions apply.)

When the underlying user agent or platform does not support these dimensions for scrolling, reflow is encouraged as this capability is important to (people) with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies.

[GreggVan]

RE NOTE 5: Notes never change what is required. They can only explain what the requirement or the provision already says. So adding the 320 - 256 text is not required in the note. Having said that, however, it also does not hurt to add it and does remove some ambiguity from people not used to reading standards. As a result, I see no problem in adding that text to the note.

RE NOTE 7: I think you might be missing the logic here. When you rescale the screen, everything gets larger. But this only requires that text reflow if there is not an exception. If there is an exception, then the text would just get larger and you would have to horizontally scroll to see it. So there's no need to talk about having the screen scale be different for different parts of the screen (which is in fact impossible anyway).
You also mentioned enlarging the font. This would, in fact, cause a problem for things that are in an exception, if it applied to this success criteria at all. But it does not. There's nothing in this success criteria that talks about increasing font, size or any requirements on what happens if you do increase the font size. This only talks about changing the effective size of the viewport and what has to happen if you do that. That is, this only talks about what happens if you have a different "full screen scale". So there is no problem with note 7 and no need to add extra text that I can see. And here adding extra text would just make it more complicated and could lead to misunderstanding. In fact, does not result in any problems with viewing other than you would have to horizontally scroll. But that's kind of obvious. If something does not wrap and you make the viewport half is wide, or less, you are obviously going to have horizontal scrolling, which can be viewed as a poor user experience, except if you can't see it at all if you don't. In which case it is not a reduced user experience, unless you are comparing it to suddenly having a physical screen, that is two or three times larger, which of course would be nicer for someone with low vision, but is beyond the authors capability.

If I'm missing something, ping back.

[mraccess77]

My view is that the intent of the criterion is to ensure that content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for vertical and horizontally scrolling content. For some people with low vision this isn't related to magnification but to the width of the content for horizontal languages. The SC itself doesn't say how this has to be achieved. I don't think Note 5 sufficiently addresses the allowance for the content area to be manipulated to achieve this independent from the window or for content that by itself is simply <= 320 CSS pixels.

Similarly, note 7 seems to imply this can only be met when the user agent or platform can display content at 320CSS pixels. This seems to miss the point of the criteria that it's not about resizing the window but about the actual width of the content itself. In my view it's totally possible for a UI as a whole to not get down to 320 CSS pixels - but that individual content can meet if <=320 CSS. In addition, the criterion is clear that this is about content that scrolls in two-dimensions at that size. So if it only requires scrolling in one dimension - say horizontally to read the content then there is no width limitation.

[maryjom]

@mraccess77 Interpreting to any size of scrollable viewport that the technology supports would require rewriting the SC to appropriately apply in that situation. The WCAG Understanding document does not account for the eventuality that web content is displayed in a smaller viewport width or height that might not be changeable to that width and there is confusion around that (e.g. iPad with side-by-side view of 2 different web pages would need to scroll in a narrower window width). This SC needs clarification by the AG WG for such situations. It is not up to WCAG2ICT to redefine the specified language in the SC which has those specific measurements in the normative language. We are not at liberty to change that.

[mraccess77]

@mraccess77 Interpreting to any size of scrollable viewport that the technology supports would require rewriting the SC to appropriately apply in that situation. The WCAG Understanding document does not account for the eventuality that web content is displayed in a smaller viewport width or height that might not be changeable to that width and there is confusion around that (e.g. iPad with side-by-side view of 2 different web pages would need to scroll in a narrower window width). This SC needs clarification by the AG WG for such situations. It is not up to WCAG2ICT to redefine the specified language in the SC which has those specific measurements in the normative language. We are not at liberty to change that.

I think there may be a misunderstanding - I'm not suggesting that this apply to the window at different viewports - the criterion itself doesn't mention viewports. The criterion mentions the content itself - the block of content being tested. Thus, my comment is about the size of the content supporting 320CSS pixels - so no change of criterion sought.

[scottaohara]

@GreggVan I think you have misunderstood the concerns raised about note 7.

We are well aware that when one rescales the screen that everything gets larger. We did not mention anything about scaling being different for different parts of the screen. I think you misunderstood the mention that there are some applications which do allow for scaling of portions within itself (for instance, via a zoom control within the application itself, separate from the system settings).

You also mentioned enlarging the font.

We did not mention enlarging font in the concern raised. So we're not sure how to take this feedback since it seems based on a misunderstanding.

@mraccess77's comment works well in restating some of our concern for note 7:

Similarly, note 7 seems to imply this can only be met when the user agent or platform can display content at 320CSS pixels. This seems to miss the point of the criteria that it's not about resizing the window but about the actual width of the content itself. In my view it's totally possible for a UI as a whole to not get down to 320 CSS pixels - but that individual content can meet if <=320 CSS. In addition, the criterion is clear that this is about content that scrolls in two-dimensions at that size. So if it only requires scrolling in one dimension - say horizontally to read the content then there is no width limitation.

[maryjom]

The biggest issue for me is the way the SC is written and applying it to things that may have very small screens (e.g. closed functionality types of ICT, like printers) and smaller scrollable areas. The SC is written with very specific scroll width or scroll height. The language in bulleted list in the SC says "at at a width equivalent to" or "at a height equivalent to". It doesn't say "less than or equal to" or "up to". If it said that, there would be less consternation about the interpretation. WCAG2ICT cannot reinterpret the language to mean "up to" and the understanding document does not clear that up in any of its language.

[GreggVan]

@scottaohara
yes i see where i misread your comment when you talked about " zooming in specific areas where users might be typing or reading (for instance an email software to compose mails / read mail content), but the rest of the UI doesn't adjust and would need to have adjustments at the OS level to make the content larger."
So all is good.

@maryjom -- I think that it says "at that width" with the assumption that it could be anything up to that. However if it DID say "anything up to that" - then it raises the question of what "anything" is. How many steps - how much resolution is needed for every point up to that. So i dont think anyone will have a problem with the "at this width/height".
(or did i miss your point)

But I do wonder on small screens (where - if we treat pixels as a physical size) the screens pass already without any zoom because they are already less than that width in physical pixels -- no?

As for the small screens on "closed functionality" -- we just list this as another provision that will have problems in closed functionality. We ran into this on electronic COVID test displays. They are so small (the devices themselves) that you cant use large print or even get very many words on the screen -- much less zoom and have anyone not mistake things. (but they did talk).

[maryjom]

The WCAG2ICT TF is currently surveying edited versions of the Microsoft-submitted proposals for Notes 5 and 7 and will discuss the results on 6 June (See survey results for question 4 on Note 5 and question 5 on Note 7.)

[maryjom]

Answer from the WCAG2ICT Task Force:
@scottaohara Thank you for your comments and especially for providing some proposed text to start from. This really helped expedite the process of addressing the issue.

The Task Force reached resolution on 13 June by making some edits to your suggested language - partly for consistency with WCAG's language, as well as a few other editorial changes. You can read the changed notes in-context in the built document for PR #378. See the section Applying SC 1.4.10 Reflow to Non-web Documents and Software Notes 5 and 7, also copied below:

NOTE 5: The intent section refers to the ability for content to reflow (for vertical scrolling content at a width equivalent to 320 CSS pixels, or for horizontal scrolling content at a height equivalent to 256 CSS pixels) when user agent zooming is used to scale content or when the viewport changes in width. For non-web software, this means that when users scale content, adjust the size of a window or dialog, or change the screen resolution, the content will reflow without loss of information or functionality, and without requiring scrolling in two dimensions; or that the application works with platform features that meet this success criterion.

NOTE 7: As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 256 CSS pixels for horizontal scrolling content.

When the underlying user agent or platform does not support these dimensions for scrolling, reflow is encouraged as this capability is important to people with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies.

When users modify zoom, scaling, and/or display resolution at the platform software level (e.g. Operating System), it impacts the size of all applications and the platform software itself. This can result in improved readability in some applications but unwanted consequences in others.

This PR will be merged once the AG WG approves the changes made (scheduled for 25 June).

[maryjom]

PR has been merged to address this issue. Closing this issue. The WCAG2ICT document is now in CfC to publish that ends on 1 July. Then the document will be published for a 30-day wide review prior to being finalized.