The Accessibility Tree: The DOM for Assistive Tech
The accessibility tree is the DOM's sibling, built for assistive tech. Browsers derive it from your HTML, exposing each element's name, role (e.g., 'button'), and state (e.g., 'checked') to screen readers.
Why it exists
A visual browser renders HTML for sighted users. But users with visual impairments need a non-visual, structured way to understand and interact with a page. The accessibility tree is the browser's solution, providing a semantic interface for assistive technologies like screen readers.
The mental model
Think of the accessibility tree as a parallel structure to the DOM. While the DOM represents the full visual and structural layout of a page, the accessibility tree is a filtered, simplified version containing only the information an assistive device needs. It's the DOM for machines, not for rendering pixels.
How it works
The browser first parses HTML into the DOM tree. It then creates the accessibility tree from the DOM. For each relevant element, it computes four key properties: its Name (how to refer to it, like a link's text), its Role (what it is, like a 'button' or 'navigation'), its State (its current status, like 'checked' or 'expanded'), and its Description (optional extra context). This tree is then exposed via platform-specific APIs to assistive technologies.
When to use it
As a developer, you don't use the accessibility tree directly. You influence its creation by writing semantic HTML. Using a <button> element instead of a automatically gives the corresponding object in the tree the correct 'button' role. When native HTML is insufficient for complex widgets, you use ARIA (Accessible Rich Internet Applications) attributes to manually add or correct information in the tree.
When not to use it
The primary footgun is ignoring it. A common mistake is building a custom component from a with a click handler. Visually, it's a button. But in the accessibility tree, it's a generic element with no role or state, making it invisible or unusable to anyone relying on assistive tech. If you build a custom interactive element, you are responsible for managing its representation in the accessibility tree.
One canonical example
Consider <button aria-pressed="true">Mute</button>. The browser creates an accessibility object with Name: "Mute", Role: "button", and State: "pressed". A screen reader announces, "Mute, pressed, button." Now consider a non-semantic version: Mute. The accessibility object has a Name ("Mute") but its Role is generic. The user gets no clue that it's an interactive button or what its current state is.
Interview question
A developer creates a custom interactive button using a <div> element with a click handler. What is the most significant impact on accessibility?
- a.Assistive technologies will perceive it as a generic element, lacking crucial semantic information like its role or state.Correct
- b.The component will be included in the accessibility tree but marked as hidden, making it undiscoverable.
- c.The browser will fail to parse the <div> as an interactive element, preventing any user interaction.
- d.The component's visual appearance will be inconsistent across different assistive technologies.
Why? this is the answer
The card states that a custom component built from a <div> with a click handler is a 'generic element with no role or state' in the accessibility tree, making it 'invisible or unusable' to assistive tech. Option A accurately describes this lack of semantic information. Option B is incorrect because the element is not marked as hidden; it's simply generic, which leads to it being functionally undiscoverable as a button.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #accessibility
- #html
- #dom
- #screen-reader
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on accessibility — each one lists the topics its interview covers.
See open roles