Wcag: Language of 1.4.10/Reflow exception seems broader than intended

Created on 25 Feb 2020  路  8Comments  路  Source: w3c/wcag

My current interpretation of the exception language for reflow, "except for parts of the content which require two-dimensional layout for usage or meaning," was that content that requires two-dimensional layout is allowed to scroll in two directions, but must still be perceivable and usable.

However, the language and formatting of the criterion could be read as saying that an app or site that contains a table, for example, does not need to be available without loss of information or functionality when zoomed. To give a concrete example, an app that contains a user-editable canvas with multiple associated toolbars has two scrollbars (which is fine), but then is also entirely unusable at 400% zoom. By the wording of the criterion, they are arguably compliant because they fall into the "except for parts of content..." wording.

Is this the intent? And if not, could the wording be adjusted to make more clear that the "except..." wording only applies to "without requiring scrolling in two dimensions"?

1.4.10 Reflow ErratumRaised Survey - Added WCAG 2.1 WCAG 2.2

Most helpful comment

@smhigley I'm wondering if changes to the second note would help address your concerns. For example, changing:

Examples of content which requires two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content.

to (changes in bold):

Examples of content which requires two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two-dimensional scrolling for such parts of the content.

This could be accompanied by some changes in the Understanding document in the 'Content exceptions for reflow' section.

All 8 comments

Hi @smhigley,

I wrote a reply to this, then re-read it, then re-read the understanding document, then started this again!

The intent so far as been that the exception is blanket, in that is applies to both the scrolling and "without loss of information or functionality" aspects.

However, it is targetted at "parts of the content", not whole pages. I.e. if you have a large data table, that can triggered scrolling for that part of the content, but not the page as a whole.

If the entire page is a canvas with toolbars, then effectively the whole page is excepted.

I don't think it was a case of intentionally wanting to except "loss of information or functionality", it was that the lack of scrolling was the difficult bit, if that's a problem then the other part may or may not be a problem. If something is allowed to scroll, it is easier to not loose content/functionality at high zoom levels.

From your experience, is that differentiation important? Or rather, is it feasible to maintain info & functioanlity in the cases where scrolling is necessary.

Ah, interesting. So a page that (for example) allows people to edit flowcharts by providing one large canvas and a couple toolbars does not need to function at all at 400% zoom? That is, it's not that the user would have to scroll in multiple directions; it's that a user would not be able to interact with the page at all unless they zoomed out?

Or, for the "parts of content" exception, if there were a word editor with a toolbar, the toolbar would not need to be functional at 400% zoom?

That seems a bit odd to me. If someone needs to zoom in that far to consume content, and part of that content is in the form of a table, how would they read that table if it doesn't need to be present at all when zoomed? It seems weird to do any work at all to make any part of a page reflow if other major, crucial parts of content and functionality aren't available at all.

Or maybe I'm misunderstanding what you're saying, which also seems likely 馃槅

agree with @smhigley ... the current normative wording can indeed be read as

Content can be presented without loss of information or functionality [...at specific sizes of CSS px width/height...] Except for parts of the content which require two-dimensional layout for usage or meaning.

which could be interpreted as "well, if it doesn't fit, it's ok if it's completely cut off (e.g. overflow:hidden) if you can make an argument that it requires that larger two-dimensional layout"

i don't think, at least based on my recollection, that THAT was the intention of the exception...but that rather the exception is more

If parts of the content do require two-dimensional layout for usage or meaning, it is however acceptable to introduce/force two-dimensional scrolling

@smhigley I'm wondering if changes to the second note would help address your concerns. For example, changing:

Examples of content which requires two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content.

to (changes in bold):

Examples of content which requires two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content. It is acceptable to provide two-dimensional scrolling for such parts of the content.

This could be accompanied by some changes in the Understanding document in the 'Content exceptions for reflow' section.

@mbgower those two changes sound great! I think that would definitely help address some of the misunderstandings around what reflow requires.

Thanks for working on this :)

The updated note was approved in this meeting: https://www.w3.org/2020/07/21-ag-minutes.html#item07
@mbgower did you have an understanding update to suggest as well?

@alastc just created a PR to address this outstanding issue assigned to me. Added @detlevhfischer as reviewer. Straight forward change to Understanding doc for 2.1. Maybe it doesn't even need to go to survey?
https://github.com/w3c/wcag/pull/1656

Was this page helpful?
0 / 5 - 0 ratings