In one paragraph
Table cell headers attributes must refer to other header elements in the same table means explicit cell relationships contain invalid or inappropriate references. Repair each listed ID and verify it identifies the correct header, not simply any existing element. Simple tables may use suitable native header and scope relationships instead, but do not delete explicit mappings from a complex table without preserving equivalent context.
Why it matters
Headers help readers interpret data without visually tracing rows and columns. Explicit headers attributes can associate a data cell with several relevant headers when a simple horizontal or vertical relationship is insufficient.
The value is a whitespace-separated list of header IDs, not their human-readable text. References to another table, a regular data cell, the same cell itself, or a stale missing ID can break the intended mapping. A valid target with the wrong subject is also misleading even when a syntax check accepts it.
Native headers and scope can be appropriate for simpler structures. A caption identifies the table but does not substitute for each cell's row and column context. Keep the actual information model intact while simplifying markup.
How WebAuditOS evaluates this finding
The supplied td-headers-attr rule inspects applicable exposed tables and cells with explicit headers attributes. It rejects its documented self-reference, missing or cross-table target, and non-header-cell cases.
Serious impact maps to high severity. Empty attributes can become review results omitted from the report. The check does not prove every required header is listed, that its content is meaningful, or that all complex relationships survive sorting and responsive changes.
How to fix it
- Identify the actual row, column, and grouped-header context for each affected cell. Do not choose targets solely because their IDs exist nearby.
- Correct explicit relationships within the table. An illustrative simple mapping is:
<table>
<caption>Illustrative delivery rate</caption>
<tr><th id="destination-h" scope="col">Destination</th><th id="rate-h" scope="col">Rate</th></tr>
<tr><th id="czechia-h" scope="row">Czechia</th><td headers="czechia-h rate-h">5 EUR</td></tr>
</table>
The values and IDs are examples. This intentionally explicit demonstration does not mean every simple table needs headers attributes.
- Keep all referenced targets appropriate header cells in the same table. Sticky clones in another table do not become valid association targets merely because they look like the original row.
- Give repeated tables and generated headers unique IDs in their relevant document scope. Update every dependent reference when an ID changes.
- If simplifying to scope, confirm that the remaining structure expresses all needed relationships. Multi-level or irregular tables may still need explicit associations or a clearer equivalent design.
- Test sorting, filtering, pagination, virtualised output, and column visibility. Header mappings can become stale when a library changes order or omits cells after the initial render.
- Inspect table navigation with supported assistive technology where practical. A checker can confirm target type while users still hear an irrelevant or incomplete context.
- Rescan reference, header coverage, and other table checks, and review incomplete results. Do not clear the finding by replacing headers values with empty strings or hiding meaningful tables.
What the fix can break
Renaming IDs can affect fragment links, scripts, and CSS. Update associations and implementation dependencies together.
Splitting a single logical table into visual header and body tables can lose semantic relationships. Consider a supported sticky design on the real headers where appropriate, rather than maintaining only a visual clone.
Do not add unrelated table header roles to data solely to satisfy an ID target test. The content must genuinely function as a header.
Questions
Can headers refer to a header in another table?
Not for the native relationship under review. Keep the correct associations within the intended table.
Does every simple table require explicit headers attributes?
No. Appropriate native th and scope relationships can be enough for simpler structures.
Does headers empty prove the mapping is unnecessary?
No. The supplied rule can omit that review case. Decide from the actual information model.
Which related checks help?
Review headers with data, data-cell headers, and the automation limits guide.
What severity does this get in the report?
High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. This rule is declared serious in axe-core, so a failure arrives as high.