The accessibility tree is a representation of a page that the browser derives from the DOM and exposes to assistive technologies such as screen readers. It contains the elements of a page along with the information needed to operate them.
At a glance
- Type
- structure the browser derives from the DOM
- Affects
- assistive technologies such as screen readers, via platform accessibility APIs
- Properties
- name, description, role, state
- Visible?
- Chrome DevTools, Accessibility tab
Last checked:
What is in the accessibility tree?
According to MDN, browsers build the tree from the DOM and pass it to the platform’s accessibility APIs. Each node has four main properties. The name says how to refer to the element, for example the link text “Read more”. The description adds further information. The role states what kind of element it is, such as button, navigation or list item. The state reports things like checked or expanded.
Markup and styles decide whether an element appears. An element with display: none is removed from the tree, and aria-hidden="true" hides it from screen readers. Semantic HTML and ARIA attributes shape roles, names and states.
Chrome DevTools can display the tree. In the Elements panel, open the Accessibility tab and switch on the accessibility tree view.
What does it mean for AI agents?
Programs can read the tree too. Playwright MCP from Microsoft works from the accessibility tree instead of screenshots, according to its project description, so it needs no vision model. How other agents read pages differs by product. Clean HTML with meaningful names helps screen reader users and is likely to help agents as well (assessment).
Google’s guidance on agent-friendly websites (web.dev, April 2026) lists the accessibility tree as one of the ways agents read a page and recommends semantic HTML and labels tied to inputs with for. A searchVIU post (2026) points to a CHI 2026 study from UC Berkeley and the University of Michigan, in which a computer-use agent worked through 60 everyday Windows tasks. With mouse and screen view it succeeded about 78% of the time. Limited to the keyboard, as a screen reader user would be, it managed about 42%.
Example
<button aria-label="Open cart">
<svg aria-hidden="true" width="16" height="16"><path d="..."/></svg>
</button>
In the accessibility tree this appears as a node with the role “button” and the name “Open cart”. The icon is not part of the tree.
Common mistakes
aria-hidden="true"on focusable elements. MDN warns against it, including on ancestors of focusable elements, because the attribute is inherited.aria-hiddenon elements that are already hidden. Withhidden,display: noneorvisibility: hidden, they are already missing from the tree.- Hiding visible content. According to MDN, only when equivalent content stays available to assistive technology.
- Divs and spans instead of
<button>and<a>. web.dev names missing semantic elements as an obstacle for agents.
FAQ
Is the accessibility tree the same as the DOM? No. It is derived from the DOM and holds the nodes that matter to assistive technology.
What is the Accessibility Object Model? A Web Incubator Community Group (WICG) effort for a JavaScript API that lets developers modify the tree and, eventually, read it. It is still a community group draft.
More on the searchVIU blog
Sources
- Accessibility tree – MDN Web Docs Glossarydeveloper.mozilla.org
- Accessibility reference – Chrome DevToolsdeveloper.chrome.com
- Accessibility Object Model – WICGwicg.github.io
- Playwright MCP – GitHub (Microsoft)github.com
- aria-hidden – MDN Web Docsdeveloper.mozilla.org
- Optimizing for AI Agents — Common Pitfalls and How to Fix Them – searchVIU blog (2026)searchviu.com
- Build agent-friendly websites – web.devweb.dev
- A11y-CUA Dataset – arXiv 2602.09310arxiv.org
- aria-hidden – MDN Web Docsdeveloper.mozilla.org
Last updated: