Accessibility tree
Slap yourself if
You think the accessibility tree is just the DOM with ARIA sprinkled on top.
Why this exists
The accessibility tree exists because the DOM is not a usable interface for assistive technologies. Browsers must translate visual, interactive content into a semantic, navigable structure — and that translation is lossy, opinionated, and easy to break unintentionally.
Mental model
The accessibility tree is a parallel representation of your UI, optimized for meaning and interaction, not pixels. What ends up there depends on semantics, roles, and browser heuristics — not your component hierarchy.
- The browser builds a separate accessibility tree from the DOM.
- Only nodes with relevant semantics are exposed.
- ARIA roles and attributes override or augment native semantics.
- Assistive technologies interact with this tree, not the DOM.
- Assuming visually hidden content is ignored by assistive tech.
- Overusing ARIA and breaking native semantics.
- Relying on divs and spans for interactive elements.
- Creating focusable elements with no accessible role.
The accessibility tree is the browser-generated semantic representation of a page that assistive technologies use, derived from the DOM but filtered and transformed based on roles, states, and heuristics.
- Interactive divs without roles or labels
- ARIA roles duplicating native elements
- Focusable elements missing names
- Accessibility treated as a visual concern
Deep dive
Premium deep dives include more internals, more scars.