-
Notifications
You must be signed in to change notification settings - Fork 70
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
"Headers attribute specified on a cell refers to cells in the same table element" [a25f45]: require headers to be th
elements
#2110
base: develop
Are you sure you want to change the base?
Conversation
@WilcoFiers I put in a change to the expectation based on the issue description, but I'm a bit hesitant about that. I think ATs handle this regardless of whether or not it points to a td or a th. We certainly don't have any fail examples here to demonstrate that. I certainly agree that the examples should be in line with the spec. But, should we:
|
@@ -36,7 +37,7 @@ This rule applies to any `headers` attribute specified on a [`cell`][] within a | |||
|
|||
## Expectation 1 | |||
|
|||
Each target's [attribute value][] is a [set of space separated tokens][]. Each token is the value of the `id` attribute of an element, that is a [`cell`][] of the same [`table`][]. | |||
Each target's [attribute value][] is a [set of space separated tokens][]. Each token is the value of the `id` attribute of an element, which is a [`cell`][] of the same [`table`][] and is a `th` element. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would feel much better about this if we had some test data showing that referencing td
s, with and without role=row/columnheader doesn't work. Would it be possible to get someone to do some testing before we say this definitely fails WCAG?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is at least invalid HTML: headers attribute, and shouldn't create a relationship: Forming relationship, step 7 only keeps the "headers".
Due to non-interference with the host language, I'd be surprised if that worked. But I agree we should test it nonetheless.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used this as a test with just regular HTML:
https://codesandbox.io/s/table-test-68d78y?file=/index.html
JAWS doesn't care if the referenced element is a td
or a th
, it reads the referenced headings in both cases. Surprisingly, NVDA and desktop Voiceover seem to ignore the headers
attribute and use the automatic calculation - they won't read td
's, but they read the th
at the top of the column rather than the th
that I referenced via headers
.
So, 2 of the 3 desktop screen readers don't handle headers properly even when they're referencing a th. The 3rd doesn't care if it's a td or a th. Given that, I'm having a hard time seeing how this rule has any real world value - the results don't seem to be a factor of what the headers attribute is referencing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear, I was using Chrome on Mac, and Edge on Windows.
<th role="columnheader" id="header1">Projects</th> | ||
<th role="columnheader" id="header2">Objective</th> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably don't need the role anymore if we do this. If we're going to fail headers
referencing td
elements we should have a new failed example for it. What we have now references an element inside the cell, which I do think is a problem.
th
elements
Co-authored-by: Wilco Fiers <[email protected]>
Updates based on #1910
Closes issue(s):
Need for Call for Review:
This will require a 2 weeks Call for Review
Pull Request Etiquette
When creating PR:
develop
branch (left side).After creating PR:
Rule
,Definition
orChore
.When merging a PR:
How to Review And Approve