Accessibility tree

A browser builds two trees from one document. The render tree decides what gets painted, and the accessibility tree decides what gets announced. Each node in the second one is mostly four facts: a role (what kind of thing this is), a name (what it is called), a state (checked, expanded, disabled, current), and a value where one applies. Assistive technology never sees your markup and never sees your pixels. It sees this tree, which is why “it looks like a button” and “it is a button” can be two different sentences.

The tree is derived, not authored. Native semantics come first: a button element arrives as a button, an h2 as a heading with a level, an input type="checkbox" as a checkbox that carries its own checked state. ARIA edits that derivation rather than adding anything to the page, which is the whole of its job description. role swaps the node’s role, aria-* sets state the DOM has no attribute for, and the accessible name is computed by a specified walk over labels and content. A div with a click handler and no role becomes a generic node: present, named nothing, announced as nothing.

Three things move an element between the two trees, and they are worth keeping straight. display: none and visibility: hidden remove it from both. Visually hidden text removes it from the painted one only, so it stays in the accessibility tree and gets read out. aria-hidden does the opposite: the element still paints, and it and its whole subtree vanish from the accessibility tree. role="presentation" (and its synonym role="none") is a lighter cut, stripping a node’s own semantics while leaving its children in place, which is how a table used for layout stops announcing rows and columns.

Below the browser sit the platform accessibility APIs the tree is exposed through: UI Automation and IAccessible2 on Windows, NSAccessibility on macOS, AT-SPI on Linux. This is why the same tree is loosely called “the accessibility API”, and why the old screen-reader term for it was the off-screen model. You can read it directly: every browser’s developer tools show the computed tree, node by node, and comparing what you see there against what you expected is faster than guessing why a screen reader said “group” out loud.