demo · v136

Accessibility tree mismatch

The chromestatus motivation that nobody actually saw: the UA shrank nested h1s to look like a lower heading, but the accessibility tree still announced them as level 1. Screen-reader users heard a perfectly flat heading outline while sighted users saw a hierarchy. Here's both views, side by side.

Comparing computed font-size vs. ARIA heading level for the same document.

1. what sighted users see

Site title (top-level h1)

Section heading (nested h1)

Deeply nested heading (h1 in section in section)

2. what the a11y tree exposes

aria-level always 1, regardless of font-size. That's what NVDA, JAWS, VoiceOver announce.

computed font-size vs. heading level

why this angle

The sibling concept shows the visual difference: nested h1s are the same size now. This concept shows the bug that made the deprecation worth doing: the pre-136 UA stylesheet visually demoted the heading without changing its semantic role. So a screen-reader user navigating by headings (H key) heard a uniform list of level-1 headings while a sighted reader saw an apparent outline. Removing the rules forces authors to either use the correct level (h2) or explicitly opt into a smaller size with author CSS — either way the visual and the semantic now match.

the code

// Both ways, the heading reports the same level — the deprecated UA
// rule only changed the painted size, not the role.
const h = document.querySelector("section h1");
h.tagName;                                   // "H1"
h.getAttribute("aria-level") ?? h.tagName[1]; // 1
getComputedStyle(h).fontSize;                 // pre-136: ~24px, 136+: ~32px