In one paragraph
Table headers in a data table must refer to data cells addresses header content that may lack a meaningful data relationship. Review the actual grid, scope, explicit mappings, and empty or filtered state before changing it. Not every temporarily empty column is automatically invalid. The supplied WebAuditOS integration omits this rule's review outcomes, so no finding does not confirm that each header describes the right data.
Why it matters
A row or column header supplies context for associated values. Misaligned spans, removed columns, stale generated headers, or a title misused as a header can make that context confusing. The correct repair depends on the data and intended operation.
Legitimate grouped headers and empty states need judgment. A column can temporarily have no results without becoming a meaningless feature, while a header styled as a section divider can claim relationships it does not actually have. Do not remove every unmatched candidate mechanically.
A caption and table header serve different purposes. A caption identifies the table's topic, while a header describes relevant data relationships. Retaining both correctly is often more useful than assigning all text one role to simplify a detector.
How WebAuditOS evaluates this finding
The supplied th-has-data-cells description uses data-table heuristics and checks non-empty relevant header cells against positional or explicit relationships. It has applicability limits and cannot fully decide the meaning of every association.
The source states that uncertain negative cases become review rather than violations and are excluded from its report. The nominal serious impact is therefore not a reported severity here. Other table-attribute rules can still flag broken references separately.
How to fix it
- Inspect the real header and its intended meaning. Determine whether it labels data, groups lower-level headers, names the whole table, or is a decorative layout cell.
- Compare the logical grid with rowspan, colspan, scope, and explicit references. A visual border can conceal a mismatch between the table model and what a reader sees.
- Keep genuine headers as appropriate th cells and map them to the data they describe. For irregular structures, use the required group or explicit association approach rather than assuming the first cell in every row is always a header.
- Move an actual table title to an appropriate caption or deliberate naming relationship, without destroying legitimate multi-column header groups.
- Handle empty and filtered results purposefully. A clear no-results message and a meaningful retained schema can be appropriate; do not invent data or delete useful columns merely to satisfy a review candidate.
- Fix the table generator so header and body changes stay coordinated. Test hidden columns, reordered fields, loading placeholders, and refreshed datasets, not only one static snapshot.
- Review keyboard and assistive table navigation where practical. Verify that the associated context is truthful and not repeatedly announced as an unrelated broad label.
- Record manual conclusions and rescan other table checks. The absence of this review-only finding is not evidence that the relationship was fully validated.
What the fix can break
Removing headers can make previously understandable cells lose their subject. Repair association errors before deleting structural context.
A broad span edit can shift the model for the entire table. Verify actual data positions and application features such as sorting and exporting.
Do not turn a data table into presentation merely to avoid a rule's applicability. If it communicates data relationships, those relationships must remain available appropriately.
Questions
Is every header without visible results wrong?
No. Review legitimate empty, filtered, or grouped states before making a change.
Does a caption replace all headers?
No. Table identity and cell relationships are different information needs.
Why can no finding coexist with a real header problem?
The supplied integration omits the rule's review outcomes, and its heuristic coverage is limited.
Which related checks help?
Review explicit headers references, table captions, and the automation limits guide.
What severity does this get in the report?
None, in practice. An axe finding takes its severity from the impact axe reports, mapped critical and serious to high, moderate to medium, minor to low, and this rule is declared serious - but in axe 4.13.0 a failing header produces a needs-review result, not a violation, so it does not reach our report. That is why the panel above states a conformance level rather than a severity.