HTML `headers` Attribute Tested Across 8 Screen Reader Pairings

The HTML headers attribute produced no measurable benefit on six of eight screen reader and browser pairings — actively worsened one and was simply ignored by three mobile pairings — per a fresh test pass just published.

Configurations ran on Firefox 155, Chrome 152, and Safari paired with NVDA 2026.2, JAWS 2026.2608.25, Narrator on Windows 11 25H2, VoiceOver on macOS 26.6.2 and iPadOS 26.6.1, and TalkBack 17 on Android 17. The setup consolidated patterns from earlier 2022 and 2023 testing into a single demo for direct comparison.

On Firefox 155 with NVDA, the demo announced compound row and column headers correctly. Adding headers changed nothing. Chrome 152 with JAWS read headers only through Ctrl+Alt+arrow table navigation; the virtual cursor went mute. Edge 152 with Narrator announced every header — also unchanged by the attribute, though arrow keys sometimes moved the wrong direction through spanned cells.

What makes Safari the exception?

Safari with VoiceOver is the one desktop pairing where headers shifts behavior — and not in the tester's favor. Once set, the research found, you must set it everywhere; otherwise VoiceOver returns the wrong axis. With the attribute applied throughout, the announce-column-header command (Ctrl+Opt+C) read both row headers when the cursor sat in the Title column, conflating axes. Strip it and column headers read normally. The macOS results do not transfer to iPadOS.

Why do mobile pairings announce nothing?

Chrome 152 with TalkBack 17 on Android 17 ignored headers and announced only the first column's row header ("Asia") — and only on row one. Firefox 155 with TalkBack reported zero headers at all, with no row or column navigation for tables. Safari with VoiceOver on iPadOS 26.6.1 announced primary column headers, ignored secondaries, and missed axis context.

How long have these defects been open?

Four tracked bugs back the findings:

• Chromium bug 40691227, 11 May 2020 — "headers attribute ignored in tables resulting in an incorrect screen reader experience." Status: New.
• Chromium bug 40818082, 24 January 2022 — "Screen readers announce spanning row header as many times as columns it spans." Status: New.
• JAWS bug 601, 24 January 2022 — wrong column header after a spanned cell. Open, no activity from Vispero.
• WebKit bug 235740, 27 January 2022 — wrong row header in VoiceOver macOS. Status: New.

MDN, citing Baseline, still reports full support for headers — a claim the tester disputes, citing a separate post that found Baseline "does not really cover baseline support."

What does the WHATWG say?

The WHATWG HTML spec defines headers on td and th; ARIA has no equivalent (per a 2022 W3C ARIA issue comment). So even if every pairing correctly read it, content authored only against ARIA still couldn't benefit.

What wasn't tested?

The tester flags limits worth repeating: only audio output was checked, not Braille displays. Mobile keyboards weren't paired. An Orca + Firefox pairing was planned but the virtual machine crashed — twice. Treat mobile results as the floor, not the ceiling.

What do regulators say?

RGAA 4.1.2 criterion 5.7.4 names the headers attribute as the only path to compliance for cells with id'd header associations; Luxembourg's RAWeb 1.1 mirrors it. A Mastodon user named Thain posted on 9 September 2026: "This is referenced as the only way to pass 5.7 criterion in the current RGAA version… We are awaiting a new version (maybe before the end of the year) that will hopefully change that."

The skeptic case stays open. A rule minted when headers was even less useful than today still picks the implementation over the measurable outcome. Whether RGAA's promised update lands before the next audit cycle, or whether Baseline's "full support" outlives its bugs — that thread is the one to watch.