Open ajanec01 opened 3 years ago
scope
is needed but missing (e.g. Passed Example 4 without scope
would fail the assignation on all its headers due to the empty td
in top-left corner; and definitely creates an accessibility issue because of this).Thanks for the feedback @Jym77 !
Yes, didn't think about scoping the rule to "non-empty data cells", and that would certainly work well with Passed example 4.
I'm not sure I'm following your thoughts on Failed example 1. Making sure that header cells have the scope attribute is most desirable but I've experienced no issues with <th>
elements without scope
not being announced properly by screen readers (when used as row headers and column headers simultaneously). From what I understood, the value of scope
if not specified or invalid is set to the auto state which relies on context. It doesn't seem to be a failure for me not to have the scope
attribute even more so that the rule does not require all data cells to have assigned header cells (that I guess would be the second rule that we haven't got just yet).
You're correct about the auto
scope, but context is easy to throw out of balance (and that could create issues). (it seems screen readers might auto-correct some of these)
Taking Passed Example 4 and stripping the scopes (and role):
<table>
<thead>
<tr>
<td></td>
<th>Breakfast</th>
<th>Lunch</th>
<th>Dinner</th>
</tr>
</thead>
<tbody>
<tr>
<th>Day 1</th>
<td>8:00</td>
<td>13:00</td>
<td>18:00</td>
</tr>
</tbody>
</table>
Now, according to specs, none of the th
is either a column header or a row header because of the empty td
in the corner. This is due to that bit of the specs:
[a cell is a column header if] The cell's scope attribute is in the auto state, and there are no data cells in any of the cells covering slots with y-coordinates y .. y+height-1 [=there is no data cells in the same line(s)].
Since there is a data cell in the same line, the th
in the first line with an auto
scope are not column headers.
Now, Chrome+NVDA seems to be a bit more clever and does announce them as headers when navigating the table. But as soon as the td
in the corner is not empty, NVDA stops to announce the headers when navigating the table (because they are not correctly assigned).
I haven't tried with other ATs.
This is obviously an accessibility problem if the headers are not correctly announced when navigating the table, and in that case it is due to them not being properly assigned to the data cells. There is a relationship conveyed by presentation (bold, top of column) that is not conveyed programmatically.
My 2c; I think we should keep this rule focused on headings, but it would be good to limit the rule to tables that have non-empty data cells in it.
Something has just occurred to me. In my opinion, it's more important for the table header to have a non-empty accessible name rather than for data cells. Besides, some of the data cells may be empty and that is not necessarily a failure. Leaving some note inside "empty data" would be a nice practice but it doesn't seem essential (e.g. <td>N/A</td>
. If we design the rule that is also checking if all data cells are empty something like below would fail and from my experience, it is a common practice.
<tr>
<th>Some header</td>
</tr>
<tr>
<td>Data 1</td>
</tr>
<tr>
<td></td>
</tr>
<tr>
<td>Data 2</td>
</tr>
So, I was thinking that possibly the rule should read "non-empty table headers..." but this would check two things, that table header has a non-empty accessible name and that the table header has assigned data cells which seems too much.
I think that a separate rule checking if a table header has non-empty accessible name would be better and this rule should stay as is.
What do you think?
There's one very important table that's really good for testing table rules - The Periodic Table of the Elements. The simplest version used in elementary chemistry has no headers at all - which causes problems with some AT due to table heuristics detecting it as a layout table: https://github.com/w3c/html-aam/issues/293
Even using the version of the Periodic Table with headers causes issues because there's a a gap in the headers between columns 3 and 4 representing the lanthanides and actinides - so you need to be careful about rules that require every cell to have headers https://github.com/w3c/html-aam/issues/293#issuecomment-650787651
We have a rule named All table header cells have assigned data cells
There are two points in the Task Force feedback that I'm not sure we should act upon. The first one being:
I think that the assumption section covers this quite well.
If we were to change the rule so that each data cell has assigned at least one header cell, the following pattern from the passed example 4 would be a failure even though it is a valid code
Either case would need an assumption. Is it worth changing the rule altogether, or should we stay with it as is?
The second point in the feedback was:
I think that the suggestion is to change the "assigned" word to associated. Assigned is currently linking to Forming relationships between data cells and header cells section of the HTML spec, which I think is valid.
@Jym77 has also raised an issue for this rule that would need to be addressed- #1517
It would be good to get input from the community before we change the rule.