Accessibility Tree
The accessibility tree is a structured representation of a web page's content and interactive elements that assistive technologies use to understand and navigate the interface. It is derived primarily from the DOM and accessibility-related properties, conveying semantic information such as roles, names, states, and relationships rather than visual appearance.
The accessibility tree is a representation of a web page designed for assistive technologies, including screen readers. While the DOM describes the document's elements and their attributes, the accessibility tree exposes the information needed to interpret those elements in an accessible way. For example, a button can be represented with a button role, a readable name, and a state indicating whether it is disabled.
Browsers construct the accessibility tree using information from the DOM, HTML semantics, ARIA attributes, and other accessibility-related properties. Native HTML elements such as `<button>`, `<input>`, and `<nav>` provide built-in semantic information. Developers can supplement or modify certain accessibility properties using ARIA when native HTML does not adequately express a component's meaning or behavior.
An accessibility node typically exposes a role, an accessible name, and relevant properties or states. The role identifies the kind of element, the name describes how it is identified to users, and states communicate conditions such as whether a checkbox is checked or a button is disabled. Relationships can also communicate connections between elements, such as which label describes a form control.
Not every DOM element appears as a separate node in the accessibility tree. Elements hidden from assistive technologies, such as those marked with `aria-hidden="true"`, are generally excluded along with their descendants, subject to accessibility implementation details. Presentational elements may also be omitted or flattened so that assistive technologies receive a more meaningful semantic structure.
Frontend engineers should use semantic HTML first, add ARIA only when necessary, and verify the resulting accessibility information with browser developer tools and assistive technologies. A visually correct page can still have an incorrect accessibility tree if controls lack accessible names, interactive elements have inappropriate roles, or important content is hidden from assistive technologies.
Key points
- The accessibility tree provides semantic information to assistive technologies independently of visual styling.
- Browsers derive accessibility information from DOM structure, native HTML semantics, and accessibility attributes.
- Important node information includes role, accessible name, state, and relevant relationships.
- Semantic HTML usually provides more reliable accessibility behavior than recreating native controls with generic elements.
- ARIA attributes can supplement or modify accessibility information but do not automatically implement keyboard interaction or behavior.
- Browser accessibility inspectors help developers examine the computed accessibility representation.
Interview questions
What is the accessibility tree, and why does it matter?
The accessibility tree is a browser-generated representation of a page's semantic content and interactive elements. It provides assistive technologies with information about what elements are and how users can identify and interact with them. Unlike the visual presentation, it focuses on roles, accessible names, states, and relationships. A well-structured accessibility tree helps screen reader users understand and navigate an interface.
How does the accessibility tree differ from the DOM?
The DOM represents the document's elements, attributes, and relationships. The accessibility tree provides a semantic view of that document for assistive technologies. Some DOM elements are omitted, combined, or represented differently in the accessibility tree. For example, a decorative element may not need its own accessibility node, while a button exposes a role and an accessible name.
How do semantic HTML and ARIA affect the accessibility tree?
Semantic HTML elements provide built-in accessibility information that browsers can use to determine roles and other properties. For example, a native button is recognized as a button without requiring a manually assigned role. ARIA can provide additional information or change certain accessibility properties when native HTML is insufficient. However, ARIA does not automatically provide keyboard interaction or the behavior expected from a native control.
How would you debug a button that is missing from a screen reader's navigation?
I would first inspect the element in the DOM and check whether it is hidden or excluded from the accessibility tree. I would verify that it has an appropriate role and accessible name and that no ancestor hides it from assistive technologies. I would inspect the browser's accessibility panel to examine its computed properties. Finally, I would test the control with keyboard navigation and a screen reader to determine whether the issue involves the accessibility representation, focus management, or interaction behavior.
What is the difference between `aria-label`, `aria-labelledby`, and a visible label?
A visible label provides text that users can see and that can be programmatically associated with a form control. `aria-label` supplies an accessible name directly through an attribute. `aria-labelledby` derives the accessible name from one or more referenced elements. When possible, a visible, associated HTML label is generally preferable for form fields because it supports both visual understanding and programmatic naming.
How would you ensure a custom dropdown is represented accessibly?
I would first determine whether a native `<select>` can satisfy the requirements, since it provides established semantics and interaction behavior. If a custom widget is necessary, I would select an appropriate accessibility pattern and implement its roles, accessible name, expanded state, and relationships. I would also implement keyboard navigation, focus management, and state updates that remain synchronized with the interface. Finally, I would inspect the accessibility tree and test the component with keyboard-only navigation and representative screen readers.