Definition: The accessibility tree is a structure the browser builds alongside the DOM. For every relevant element it holds the role, name, state and, where there is one, a description. Screen readers and other assistive technology read this structure through the operating system's accessibility interface – not what is drawn on screen [1][2].
German: Accessibility Tree · Also: a11y tree · Last reviewed: 27 September 2026
How it is built
The browser reads the HTML and gives each element a role: <button> becomes a button, <nav> a navigation region, <h2> a level-2 heading. Which element maps to which role is defined in the W3C's HTML-AAM specification [2]. ARIA attributes can add to or override those roles. The browser computes the name by its own rules – see accessible name.
CSS plays a part too. Anything with display: none or visibility: hidden is left out of the tree, while text generated with ::before and ::after can appear in it. Pure layout elements with no meaning, such as most <div>s, get no role.
The browser passes the tree on through an operating-system interface – UI Automation on Windows, for example, or the Accessibility API on macOS. That is where the screen reader picks it up [3].
An example
| HTML | In the accessibility tree |
|---|---|
<button>Send</button> | button, name "Send" |
<a href="/contact/">Contact</a> | link, name "Contact" |
<h2>Delivery</h2> | heading, level 2, name "Delivery" |
<input type="checkbox" checked> with <label> Terms | checkbox, name "Terms", checked |
<div class="btn">Send</div> | text only, no role, not operable |
The last row is at the heart of many barriers. Visually, the first and last entries are identical; in the tree, only one of them has a role.
How to see it
In Chrome, open the developer tools, select an element and choose the Accessibility pane. It shows the role, name and properties, and optionally the whole page's tree [4]. Firefox has a dedicated Accessibility Inspector [5]. A look there often shows within seconds why a button is silent.
Common misunderstandings
- "What you see is what's in the tree." No. A styled
<div>looks like a button and is just text in the tree. - "Hidden is hidden." Visually hidden text (with an
sr-onlyclass, say) stays in the tree and is read out.aria-hidden="true"removes an element from the tree but not from the Tab order. - "ARIA fixes everything." ARIA only changes the entry in the tree, not the behaviour. See ARIA.
How Reviseberg handles it
axe-core computes roles and names by the same rules as the browser. Reviseberg uses it to report, among other things, controls with no name, invalid roles, and elements removed from the tree with aria-hidden that can still receive focus. The keyboard agent's trail records the role and name of the focused element at every step. What a particular screen reader actually announces from the tree is not something Reviseberg checks: a screen reader agent is not part of Reviseberg today. That is what manual testing with NVDA or VoiceOver is for.
Related terms
Accessible name · ARIA · Semantic HTML · Screen reader · Assistive technology