Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Language of 1.4.10/Reflow exception seems broader than intended #1049

Closed
smhigley opened this issue Feb 25, 2020 · 11 comments
Closed

Language of 1.4.10/Reflow exception seems broader than intended #1049

smhigley opened this issue Feb 25, 2020 · 11 comments
Assignees
Projects

Comments

@smhigley
Copy link

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"?

@alastc
Copy link
Contributor

alastc commented Feb 26, 2020

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.

@smhigley
Copy link
Author

smhigley commented Feb 26, 2020

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 😆

@patrickhlauke
Copy link
Member

patrickhlauke commented Feb 26, 2020

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"

@patrickhlauke
Copy link
Member

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

@alastc alastc added the ErratumRaised Potential erratum for a Recommendation label Mar 6, 2020
@alastc alastc added this to To do in WCAG 2.2 via automation Jun 17, 2020
@alastc alastc moved this from To do to In progress in WCAG 2.2 Jun 24, 2020
@alastc alastc moved this from In progress to To Survey in WCAG 2.2 Jun 26, 2020
@mbgower mbgower self-assigned this Jul 7, 2020
@mbgower
Copy link
Contributor

mbgower commented Jul 7, 2020

@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.

@alastc alastc moved this from To Survey to In progress in WCAG 2.2 Jul 14, 2020
@alastc alastc moved this from In progress to To Survey in WCAG 2.2 Jul 15, 2020
@smhigley
Copy link
Author

@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 :)

alastc added a commit that referenced this issue Jul 28, 2020
@alastc
Copy link
Contributor

alastc commented Jul 29, 2020

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?

mbgower added a commit that referenced this issue Feb 25, 2021
As per #1049 have added supplemental information into the Understanding document to complement the second note below the normative text.
@mbgower
Copy link
Contributor

mbgower commented Feb 25, 2021

@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?
#1656

@mbgower
Copy link
Contributor

mbgower commented Sep 10, 2021

@smhigley The wording change to the note are published. The similar modifications to the Understanding document were created as a PR and merged (and will appear as part of the published version at some point) so I'm closing this. Here's the diff on the changes
If you have any follow up, feel free to reopen

@mbgower mbgower closed this as completed Sep 10, 2021
WCAG 2.2 automation moved this from To Survey to Done Sep 10, 2021
@scottaohara
Copy link
Member

scottaohara commented Sep 10, 2021

@mbgower would this note not need to be updated in the actual spec section for the reflow SC? Now the notes are different when viewing the spec vs the understanding doc

@patrickhlauke
Copy link
Member

indeed, to clarify it seems https://www.w3.org/TR/WCAG21/#reflow and https://www.w3.org/WAI/WCAG21/Understanding/reflow.html are now out of sync, which I didn't think was even possible since the understanding doc pulls the same source as the normative SC when the page is constructed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
WCAG 2.2
  
Done
Development

No branches or pull requests

5 participants