The `headers` Attribute Is Broken. Stop Using It.

We write HTML attributes to communicate structure. The headers attribute exists specifically to tell screen readers how complex table cells relate to their headers. Across every major screen reader and browser combination tested in 2026, it either does nothing useful or actively makes things worse.

Adrian Roselli's September 2026 testing (opens in new window) is the clearest documentation yet of a problem that has persisted for years: the headers attribute in HTML tables is, in his words, "largely useless." This isn't a minor edge case. It affects how blind and low-vision users navigate data tables — one of the most information-dense structures on the web. The practical implications for higher education, government data portals, and transit information systems are significant.

What the Testing Actually Found

Roselli tested four screen reader and browser combinations against tables both with and without the headers attribute. The results are damning in their consistency.

Firefox / NVDA handled spanning headers correctly with or without headers. Adding the attribute changed nothing. The browser already understood the table structure from scope and colspan/rowspan alone.

Chrome / JAWS showed similar behavior. The headers attribute had no effect. JAWS navigated compound headers correctly through table navigation mode regardless of whether the attribute was present.

Edge / Narrator also showed no difference between tables with and without headers. Narrator was more verbose than the other combinations — sometimes excessively so — but the attribute itself contributed nothing to that output.

Safari / VoiceOver on macOS is where things get genuinely problematic. Once you begin setting headers attributes, VoiceOver appears to require them everywhere. Partial implementation creates wrong-axis announcements: cells in the Title column report row headers when asked for column headers. The attribute doesn't just fail to help — it actively misleads users.

The mobile picture is worse. Roselli notes that mobile screen reader and browser pairings "generally ignore row and column headers, spanned or not." The headers attribute provides no additional benefit on mobile, and the underlying header structure isn't being reliably communicated regardless.

Why This Matters: Compliance vs. Functional Accessibility

The headers attribute failure illustrates a critical gap between specification intent and implementation reality. WCAG 1.3.1 (Info and Relationships) (opens in new window) requires that information conveyed through presentation be available to assistive technology. Complex data tables with compound or spanning headers are exactly the scenario this criterion addresses.

But here's the problem: WCAG compliance isn't achieved by adding the technically correct attribute. It's achieved when users can actually perceive the relationships. Automated tools will pass a table that includes headers attributes without flagging issues. The attribute is present, the syntax is valid, the axe rule passes. But the user experience is broken. Automated testing cannot detect this class of failure — only manual screen reader testing reveals it.

Roselli's own note confirms this: "Browser dev tools do a poor job of exposing table heading relationships in their accessibility inspectors, so manual screen reader testing is necessary." The tooling gap is real, and it's not getting smaller.

The Practical Decision Framework

Given these findings, here's how to approach complex data tables now:

For Simple Tables

Use scope="col" and scope="row" on <th> elements. This works reliably across all tested combinations. Don't add headers — it provides no benefit and introduces Safari risk.

For Tables with Spanning Headers

Roselli's core finding is that desktop screen reader and browser pairings handle spanned header cells "just as well without a headers attribute as with." Use colspan and rowspan with appropriate scope values. Test manually. The structure communicates correctly without headers in Firefox/NVDA, Chrome/JAWS, and Edge/Narrator.

For Safari / VoiceOver Users

Safari is the mild exception Roselli identifies. Without headers, VoiceOver announces column headers but only the first of compound headers — imperfect but functional. With headers partially implemented, behavior degrades. The safest path: avoid headers entirely and accept VoiceOver's partial compound header support as the current ceiling.

For Mobile Users

The mobile situation requires a different approach entirely. Since mobile screen readers generally ignore header relationships regardless of markup, consider whether complex spanning tables are the right format for mobile contexts. Restructuring data for simpler presentation — or providing an alternative text summary of the table's key relationships — may serve users better than any attribute solution.

| Combination | headers Effect | Spanning Headers Without headers | Recommendation | |---|---|---|---| | Firefox / NVDA | None | Works correctly | Use scope only | | Chrome / JAWS | None | Works correctly | Use scope only | | Edge / Narrator | None | Works correctly | Use scope only | | Safari / VoiceOver macOS | Degrades with partial use | Partial (first compound header only) | Avoid headers | | Mobile (all) | None | Generally ignored | Consider restructuring |

The Broader Pattern

This situation reflects a recurring challenge in accessibility implementation: specifications that describe ideal behavior, implementations that vary significantly, and practitioners caught between them. Following the spec doesn't guarantee the outcome the spec intends.

For organizations building data-heavy interfaces — university course catalogs, transit schedule tables, government data portals — this has concrete implications. Complex tables with compound headers are common in these contexts. The instinct to add headers attributes for compliance documentation purposes is understandable. But Roselli's testing shows that instinct produces no user benefit and potential harm in Safari.

The Northeast ADA Center's guidance (opens in new window) on accessible information systems consistently emphasizes that technical compliance and functional accessibility are not the same thing. This table testing is a precise illustration of that gap.

What to Do This Week

If your codebase contains complex data tables with headers attributes, the remediation path is straightforward:

1. Audit existing tables for headers attribute usage. Flag any table with spanning headers.
2. Test manually with NVDA/Firefox and VoiceOver/Safari at minimum. Automated tools will not surface these issues. Structural table problems routinely escape automated review.
3. Remove headers attributes from tables where scope and spanning attributes already communicate structure correctly.
4. Simplify where possible. The best solution to a table that's too complex for screen readers to navigate is often a less complex table.
5. Document your testing. Record which screen reader and browser combinations you tested, what you found, and what you changed. This documentation is the evidence base that matters under 28 CFR Part 35 (opens in new window) for Title II entities and equivalent standards for Title III.

The headers attribute was specified to solve a real problem. In 2026, it doesn't solve it. Build your tables around what actually works.