Should all table header cells have assigned data cells?

[ajanec01]

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 don't think it is an accessibility problem if a header cell exists without an assigned data cell. I think it would be better if a rule checked that a table data cell has an assigned header cell that exists instead.

I think that the assumption section covers this quite well.

This rule assumes that table header cells have a relationship conveyed through presentation with other cells within the same table. This excludes edge cases such as a table definition where there is only one header cell, or a table definition where there are multiple headers and no other cells. In such scenarios the rule fails, but success criterion 1.3.1 Info and Relationships could still be satisfied.

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

<table role="grid">
	<thead>
		<tr role="row">
			<td></td>
			<th scope="col" role="columnheader">Breakfast</th>
			<th scope="col" role="columnheader">Lunch</th>
			<th scope="col" role="columnheader">Dinner</th>
		</tr>
	</thead>
	<tbody>
		<tr role="row">
			<th scope="row" role="rowheader">Day 1</th>
			<td>8:00</td>
			<td>13:00</td>
			<td>18:00</td>
		</tr>
	</tbody>
</table>

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:

... not sure what assigned means, there is no such requirement as i see.

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.

[Jym77]

• Concerning the "direction" of the rule: I think it is OK the way it is now, with the assumption. I agree that checking if non-empty data cells have assigned headers is also a good idea but should be a separate rule (and as far as I can tell, current Passed Example 4 would still pass that new rule). I agree that Failed Example 1 is probably not that good and could be replaced with a case where 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).
• "assigned" is the precise word used in the spec that are linked from the rules: the algorithm is called "algorithm for assigning header cells" and the word "assign" is consistently used in the spec to name that relationship. Using any other term to name that relationship would just create confusion.

[ajanec01]

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

[Jym77]

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.

[WilcoFiers]

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.

[ajanec01]

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?

[dd8]

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:
w3c/html-aam#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
w3c/html-aam#293 (comment)