Empty table headers are flagged as a failure of WCAG 1.3.1

[fstrr]

Product: axe Extension

Expectation:
I don't think an empty table header (e.g. <th></th>) is a failure of WCAG 1.3.1 Info And Relationships, which is what Axe flags and tags this code as. It's definitely best practice to have text in a table heading, but I don't think this is a WCAG failure. 1.3.1 says:

"Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text."

If a header cell is marked up as a header cell, is in the same same row as all the other header cells, and styled differently from non-header cells, I'd argue that the presentational information, structure, and relationships are programmatically available. There's no text, so there's nothing to present visually or programmatically.

I'd expect to see this flagged as Best Practice rather than a WCAG conformance issue.

Actual:
This example is flagged in Axe with an issue tag of "wcag131":

<table>
  <tr>
   <th>First Name</th>
   <th>Last Name</th>
   <th>Email Address</th>
   <th></th>
  </tr>
  <tr>
    <td>Sarah</td>
    <td>Smith</td>
    <td>sarah.smith@example.com</td>
    <td><button type="button">Edit</button><button type="button">Delete</button></td>
 </tr>
</table>

Motivation:
I don't believe that this is a WCAG failure, so would like to see this moved to a best practice recommendation.

axe-core version: 4.4.1
Browser: Chrome 98

[straker]

Thanks for the issue. So the reason we flag empty table headers as a failure of WCAG 1.3.1 is because the ARIA spec requires columnheader and rowheader to have an accessible name. Because it's required, it can't be a best practice.

[straker]

In this particular case, to fix the issue you could replace the empty th with an empty td since there is no header for the column.

[fstrr]

Thanks for that information—that's useful. A couple of follow-ups:

1. Would Name, Role, Value be a better criterion if an accessible name is required?
2. I can't see anything in the HTML spec for the th element that says a table header has to have an accessible name. If the table contains no ARIA, then should it be subject to the requirements in the ARIA spec? If I've missed something in the HTML spec, then please let me know.

[straker]

So when mapping HTML elements to ARIA roles, the ARIA in HTML spec is used to determine the implicit AIRA role of the element.

As for the criterion, I think @WilcoFiers will have to answer that one.

[fstrr]

Thanks. Just to muddy the waters: Axe currently has empty headings (h1–h6) as best practice with a low user-impact Headings must not be empty. If I look at the ARIA in HTML spec heading role and then the ARIA 1.2 heading role, that also shows that an accessible name is required. Why are empty h elements a low-impact best practice but empty th elements a failure?

[WilcoFiers]

Makes sense I suppose. Francis would you be up for opening a pull request? You can change the tags by editing this file, and then remove the reviewOnFail line.
https://github.com/dequelabs/axe-core/blob/develop/lib/rules/empty-table-header.json

The impact is already set to minor so that won't need to change.

[padmavemulapati]

Validated with the latest axe-core develop branch code base with a source of axe.js, now empty-table-header rule is now best-practice failure not with wcag incomplete issue