The accessibility tree is a semantic representation of a web page that the browser builds from the DOM and CSS and exposes to assistive technologies such as screen readers, voice control software and switch devices. Each node in the tree describes an element by its role, accessible name, description and states, for example a button named “Submit order” that is currently disabled.
In web accessibility, the accessibility tree is the interface between a page and the people who do not perceive it visually or do not operate it with a mouse. Assistive technologies never read the visual rendering; they read this tree through the operating system’s accessibility API. What is missing or wrong in the tree is therefore missing or wrong for the user.
How the browser builds the accessibility tree
The browser derives the accessibility tree in parallel with the render tree. It starts from the DOM, applies the implicit semantics of each HTML element, adds or overrides information from ARIA attributes, takes CSS into account, and then prunes nodes that carry no meaning for assistive technologies.
Each browser maps the tree to the platform accessibility API of the operating system, so the same page is exposed differently on each platform while carrying the same semantics.
| Platform | Accessibility API | Typical assistive technology |
|---|---|---|
| Windows | UI Automation, IAccessible2 | NVDA, JAWS, Narrator |
| macOS and iOS | NSAccessibility and UIAccessibility | VoiceOver |
| Linux desktop | AT-SPI | Orca |
| Android | Android accessibility framework | TalkBack |
The tree is simplified compared with the DOM. Purely presentational wrappers such as many generic div and span elements are usually omitted or flattened, while text nodes, controls, headings, landmarks, lists and tables remain. As a result, a page with thousands of DOM nodes may expose only a few hundred meaningful accessible objects.
Properties of an accessible object
Every node in the accessibility tree carries a small set of standardized properties. Assistive technologies announce and operate elements based on these properties alone, which is why getting them right matters more than visual appearance.
| Property | Meaning | Typical source |
|---|---|---|
| Role | What the element is | HTML element or ARIA role |
| Accessible name | What the element is called | Text content, label, alt text or aria-label |
| Description | Additional explanatory text | aria-describedby or title |
| States | Current condition, such as checked or expanded | HTML attributes or ARIA states |
| Value | Current value of a control | Input value, slider position |
| Relationships | Links to other nodes | Labels, controls, owned elements |
The accessible name is calculated by a defined algorithm, the accessible name and description computation, which checks sources in a strict order of priority. An aria-labelledby reference overrides an aria-label, which in turn overrides a native label or the element’s text content. Misunderstanding this order is a frequent cause of controls being announced with unexpected or duplicated names.
How HTML, ARIA and CSS shape the tree
Three layers influence the accessibility tree, and each can add, change or remove information. Native HTML provides the most robust semantics; ARIA adjusts them; CSS can hide content or, in some cases, alter the exposed structure.
| Technique | Effect on the accessibility tree | Visual effect |
|---|---|---|
| Native button element | Role button, focusable, keyboard operable | Rendered as a button |
| role attribute on a div | Changes the exposed role only | None, behavior must be scripted |
| aria-hidden set to true | Removes the element and its subtree | Still visible on screen |
| display: none | Removes the element from the tree | Hidden |
| Visually hidden CSS class | Keeps the element in the tree | Hidden from sighted users |
| CSS generated content | Often included in accessible text | Visible text added by CSS |
The table shows why ARIA changes semantics but not behavior. Giving a div the role of a button tells assistive technologies it is a button, but the developer must still add keyboard focus and key handling. The first rule of ARIA use is therefore to prefer a native element whenever one exists.
Inspecting and testing the accessibility tree
All major browser developer tools include an accessibility inspector that shows the computed tree, the role and name of each node, and how the name was derived. Some can display the full tree view instead of the DOM, which makes gaps in structure easy to spot.
Automated testing tools read the same computed information to detect missing names, invalid roles and broken relationships. Browser automation frameworks can also select elements by role and accessible name, which encourages tests that match how assistive technology users find controls. Automated checks, however, find only part of the real problems; a manual review with a screen reader remains essential for judging whether names and order make sense.
Common mistakes that break the accessibility tree
Most defects in the accessibility tree come from custom components and hiding techniques applied without considering their semantic effect.
- Clickable divs without roles: they appear as plain text, so screen reader users do not know they can act on them.
- Icon buttons without names: the button is announced only as “button”, with no purpose.
- aria-hidden on focusable elements: keyboard focus lands on something the tree does not contain.
- Conflicting labels: an aria-label that differs from visible text confuses voice control users.
- States not updated: a menu that opens visually but keeps aria-expanded set to false misleads users.
- Heading levels chosen for size: the tree then reports a misleading document outline.
Stripped to the essentials
Every web page has a hidden description that the browser writes for assistive tools. That description is the accessibility tree. It lists each heading, link, button and form field. It also gives each one a name and a status.
A screen reader reads this list aloud instead of looking at the screen. If a button has no name in the list, the user hears only “button”. Clear structure in the code creates a clear description, so everyone can use the page.
Where it is applied
A travel booking site receives complaints from blind customers who cannot choose a seat. The seat map is built from styled div elements with click handlers. In the browser’s accessibility inspector, the developers see that each seat appears only as generic text such as “14C”, with no role, no state and no indication of whether it is free.
The team rebuilds each seat as a native button with an accessible name like “Seat 14C, aisle, available”, marks selected seats with the pressed state, and groups rows with labeled containers. After the change, a screen reader announces every seat with its status and lets users select it with the keyboard. Testing with two screen readers confirms that customers can now complete the booking independently.