Detailed explanation
The accessibility tree is a browser-generated representation of a page’s user interface for assistive technologies, including screen readers. While the DOM describes the document’s elements and text, the accessibility tree describes their accessible meaning: roles such as button or heading, names such as “Submit”, and properties or states such as checked, expanded, or disabled. Browsers expose this information through platform accessibility APIs, allowing assistive technologies to interpret and interact with the interface without relying on its visual appearance.
The accessibility tree is derived from the DOM, but it is not a one-to-one copy. The browser considers HTML semantics, CSS visibility, ARIA attributes, and relationships between elements when constructing it. Some presentational containers may be omitted or flattened, while meaningful text and controls remain exposed. Elements hidden with display: none are normally excluded. An element with aria-hidden="true" is also excluded, along with its descendants, even though it may remain visible on screen. These differences explain why inspecting only the DOM cannot confirm accessibility.
Semantic HTML supplies useful accessibility information automatically. For example, <button>Submit</button> normally exposes the button role and an accessible name of “Submit”; it also provides native focus and keyboard activation behaviour. A <div onclick="...">Submit</div> may expose its text, but the click handler does not automatically give it button semantics or keyboard support. Adding role="button" supplies semantics, while tabindex="0" makes it keyboard-focusable; neither implements activation with Enter and Space. An aria-label is unnecessary when suitable visible text already supplies the accessible name.
ARIA can supply or adjust roles, names, states, and relationships, but it does not implement interaction behaviour. For example, aria-expanded must stay synchronised with whether a disclosure is open. In interviews, explain the distinction between document structure, accessible semantics, and actual interaction. A strong practical answer also mentions inspecting the browser’s accessibility tools, checking computed roles and names, and testing keyboard navigation and screen-reader output.
Key points to remember
- The accessibility tree exposes meaningful UI information through platform accessibility APIs.
- It is derived from the DOM and rendering information, not copied node for node.
- Accessible roles, names, states, and relationships help assistive technologies interpret controls.
- Native HTML controls provide semantics and interaction behaviour that ARIA alone cannot provide.
- Validate computed accessibility information alongside keyboard and screen-reader behaviour.
Common mistakes candidates make
- Assuming every DOM node appears unchanged in the accessibility tree.
- Claiming a clickable div exposes nothing, rather than explaining that it lacks native button semantics and keyboard behaviour.
- Using aria-hidden on focusable controls and assuming it also removes them from keyboard navigation.
Likely follow-up questions
How is an element’s accessible name calculated?
The browser follows an accessible-name computation algorithm using sources such as aria-labelledby, aria-label, associated HTML labels, and element content. Which sources apply depends on the element; applicable aria-labelledby generally takes precedence over aria-label and native naming sources.
How do aria-hidden="true" and role="none" differ?
aria-hidden="true" excludes an element and its descendants from accessibility exposure. role="none", also called presentation, generally removes the element’s own semantics without hiding its text or meaningful descendants, subject to rules that preserve semantics for focusable elements.
How would you debug an incorrectly announced control?
Inspect its computed role, accessible name, and states in browser accessibility tools, then check the HTML, labels, and ARIA attributes that produced them. Test keyboard focus and activation, and verify the announcement with a screen reader because tree inspection alone does not validate the complete interaction.
Interview tip: Start with the DOM-versus-accessibility-tree distinction, then compare a native button with a clickable div to demonstrate both semantics and behaviour.