Accessibility tree

Every browser maintains a second model of the page alongside the DOM. It keeps only what assistive technology needs: for each element, a role saying what kind of thing it is, an accessible name saying what it is called, a state saying whether it is checked, expanded or disabled, and a position in a hierarchy that follows document order. A screen reader never reads your markup. It reads this tree, which the browser computes from your markup, your ARIA attributes and its own defaults for each element.

This is why two components that look identical can behave completely differently for somebody who cannot see them. A div styled to look like a button arrives in the tree with no role, no name and no keyboard behaviour, so assistive technology announces an unlabelled group that nothing can activate. The visual layer and the accessibility layer are generated from one source without being the same thing, and a design review can only ever inspect one of them. Knowing the tree exists changes where you look the moment somebody reports that a control is unusable.

Reading the tree in practice

• Open the accessibility pane in your browser developer tools and select a node. The computed role, name, state and tree position shown there are the ground truth an assistive technology receives.
• Check the accessible name first. Most reported problems turn out to be a control with no name at all, a name computed from the wrong source, or a name that repeats the visible text around it.
• Check what is missing. Content marked with aria-hidden, or removed from the tree by the way it is hidden in CSS, is invisible to a screen reader while still rendering on screen.
• Check the order. The tree follows the DOM rather than the visual layout, so any styling that reorders content can produce a reading sequence nobody intended.

Automated checking reads the accessibility tree and can prove that a name is absent; it cannot judge whether the name that is present actually describes the control.