1.4.10 Reflow and having more nuance for tables

[patrickhlauke]

Prompted by @WayneEDick's comment on the wai-ig mailing list https://lists.w3.org/Archives/Public/w3c-wai-ig/2020AprJun/0112.html in a discussion about reflow and tables

The big problem with scroll bars is they are not useful for large print. If
the data in the cell is text the scroll bar forces horizontal scrolling.
Evan worse scroll bars often blow off the screen in large print (or low
resolution). Scrolling to get from column to column is ok in tables, but
scrolling within columns is not.

and my comment on that https://lists.w3.org/Archives/Public/w3c-wai-ig/2020AprJun/0113.html

noting that the normative wording of the SC (and even the
informative understanding document) doesn't make that particular
distinction in its exception. It exempts tables pretty much wholesale -
when it should probably have been a lot more nuanced.

I'm wondering if it may be possible to patch/address this in a bit more detail at least in the understanding document - clarifying that the exemption for tables is for keeping/allowing the two-dimensional relationship to remain intact, but that individual cells should not, by virtue of their content itself, require two-dimensional scrolling...i.e. you should be able to read/consume the content of an individual cell without needing to scroll in two dimensions.

related, this older issue about carousels (and similar widgets) #668 could possibly also be clarified along similar lines?

[patrickhlauke]

though thinking about this further, it may be a substantive change (so needs to change in the normative SC text), as it changes the assumed wholesale exemption of tables - though i'm sure it could retrospectively be argued that even under "Except for parts of the content which require two-dimensional layout for usage or meaning" it's difficult to argue that an individual cell may require two-dimensional scrolling, while it is far more reasonable to assume that it's only the table as a whole that was meant...

but probably not clear cut either way.

[JAWS-test]

See also #932

[WayneEDick]

The criterion is ambiguous. The following explanation from the Understanding doc encapsulates this ambiguity. Complex data tables have a two-dimensional relationship between the headings and data cells. This relationship is essential to convey the content. This Success Criterion therefore does not apply to data tables. It is clear that the two-dimensional semantics is the only necessary semantic to protect. But this somewhat carelessly exempts data tables. Here is the bottom line. Horizontal scroll bars don't work on text. I guess the decision is a moral one. The intent of the exemption was to protect the functional relationship between headings and row data. It was not really meant as a loop hole to let authors present text that people with low vision cannot read. As an example of tabular text access I suggest enlarging your browser view to 400% and attempting to read this email in your favorite web mail client.

…

On Thu, May 21, 2020 at 7:45 PM JAWS-test ***@***.***> wrote: See also #932 <#932> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1129 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6Q4F47DMUTSE2CTXFCX5LRSXRMRANCNFSM4NHE62KQ> .

[yatil]

I think this is already covered in the SC:

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

• Vertical scrolling content at a width equivalent to 320 CSS pixels;
• Horizontal scrolling content at a height equivalent to 256 CSS pixels.

Except for parts of the content which require two-dimensional layout for usage or meaning.

While the note says tables are examples where two-dimensional layout is required for usage or meaning, I don't think a data cell itself requires two-dimensionality for stage or meaning.

I have never thought about that this way, but that probably means that in responsive tables you want to add a th, td {max-width: 85vw; } to your CSS to avoid individual columns grow beyond the screen. And maybe even the use of CSS scroll snap points could help with usability…

[patrickhlauke]

I'm not disagreeing about the need for having individual cells not requiring scrolling of course. But the current normative wording is causing confusion, and I don't think the understanding doc is making it clear enough that it's not a wholesale exemption of anything in a table - in fact, the wording

This Success Criterion therefore does not apply to data tables.

in the understanding doc https://www.w3.org/WAI/WCAG21/Understanding/reflow.html seems like a pretty clear-cut wholesale exemption with little nuance. If it was indeed the original intent that tables are exempt, but data cells themselves aren't, then this should at least be added/clarified right there in the understanding document. Because as it stands, to me it clearly exempts them outright.

[patrickhlauke]

Here is the bottom line. Horizontal scroll bars don't work on text. I guess
the decision is a moral one.

It should not be a "moral one". Can't have success criteria (that are supposed to be mostly unambiguous / testable) come down to "if you're a good person, you'd fail this"...

[mraccess77]

I'd support the requirement to have a cell as a unit meet the requirements --but I agree with Patrick that the wording doesn't really support that. Is this an errata or something for WCAG 3.0?

[mraccess77]

Regarding vw units -- I thought they could prevent zooming? My experience with CSS snap is that it can be disconcerting to the user even if it's implemented in a way that works with zoom - but it is sometimes implemented in ways that is not supportive of zooming where fixed sizes with breakpoints are used.

[patrickhlauke]

Regarding vw units -- I thought they could prevent zooming?

yes, but in this case, it's actually what you want because you want to say "make this container as wide as the viewport/browser window size" to avoid it being wider and requiring horizontal scrolling (noting that @yatil proposed using these to define the container dimension, not the font size)

[yatil]

Yes, in my hypothetical example, the CSS would say “let the column be as narrow as it can be but do not exceed 85% of the screen’s viewport”, this would ensure that (depending on the margins), some of the content in the next column is visible as an indicator that there is content to scroll to. It should not grow with the font size as the column would then exceed the width of the viewport, causing horizontal scrolling to read all content inside of a column.

[alastc]

I've done a small PR to run past the group. If successful, it would be worthwhile creating a brief technique for max-widthing data cells.

[alastc]

Agreed by the group: https://www.w3.org/2020/07/21-ag-minutes.html#item09