-
Notifications
You must be signed in to change notification settings - Fork 254
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
1.4.10 Reflow and having more nuance for tables #1129
Comments
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. |
See also #932 |
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>
.
|
I think this is already covered in the SC:
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 |
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
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. |
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"... |
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? |
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. |
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) |
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. |
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. |
Agreed by the group: https://www.w3.org/2020/07/21-ag-minutes.html#item09 |
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
and my comment on that https://lists.w3.org/Archives/Public/w3c-wai-ig/2020AprJun/0113.html
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?
The text was updated successfully, but these errors were encountered: