The accessibility tree is a simplified version of the DOM generated by the browser. For each relevant element it holds three pieces of information: the role (button, link, heading), the name (the label) and the state (for example selected or expanded). Google calls it a page’s “semantic summary”, used by assistive technologies such as screen readers (web.dev, April 2026). Increasingly, AI agents read it too.
How does the accessibility tree work?
The browser derives the tree from HTML and CSS and leaves out everything that is purely visual. According to Tory Gray, what remains is mainly headings, page copy, links and buttons (Sitebulb webinar, June 2026). Anything hidden with CSS does not appear in the tree — including a hidden heading.
A comparison shows how the HTML determines the entries:
| HTML | Role in the tree | Name |
|---|---|---|
<button>Add to basket</button> | button | Add to basket |
<span onclick="…">Add to basket</span> | text | — |
<label for="qty">Quantity</label><input id="qty"> | text field | Quantity |
Jairo Guerrero tested the second example: after an “Add to cart” button was switched from the button tag to span, it no longer appeared as a button in Chrome’s accessibility tree. An agent then only recognises text and does not trigger a purchase (AirOps, July 2026).
How do AI agents use the accessibility tree?
According to Google, browser agents read a page through screenshots, the DOM and the accessibility tree (Google Search Central, AI optimisation guide, July 2026). For the agent, the tree is a precise map of the controls that ignores the visual “noise” of CSS. Screenshots, by contrast, are slow and expensive and serve as a fallback when the structure is unclear (web.dev, April 2026).
OpenAI describes the same principle for its browser: ChatGPT Atlas uses ARIA roles and labels — the same ones screen readers use — to understand a page’s structure and interactive elements (OpenAI, help article for publishers, as of September 2026). Jessica Frederick sums up the reason: what screen-reader users and agents have in common is that they cannot see the page.
Why does the accessibility tree matter for AI visibility?
Whether an AI system cites a page is not known to depend on the tree — that is decided by grounding and content. The tree becomes important as soon as an agent has to act: send an enquiry, configure a product, complete a purchase (agentic commerce). A button that is missing from the tree does not exist for the agent.
Google now checks this itself: the experimental Lighthouse category “Agentic Browsing” assesses, among other things, a page’s accessibility (Chrome for Developers, July 2026). Adding WebMCP tools to a page builds on this foundation.
How much ARIA does a website need?
Less than many people assume. Many semantic HTML elements carry their ARIA role implicitly; headings need no extra label, explains Jessica Frederick (Sitebulb webinar, June 2026). Google recommends building controls with <button> and <a> and adding role and tabindex only when semantic HTML is not possible (web.dev, April 2026).
Tory Gray warns against misusing ARIA labels the way alt text used to be misused — with keywords instead of descriptions. That makes the page worse for screen-reader users and gives agents no additional information.
What does this mean for your website?
- Check: open the tree in Chrome DevTools and verify that the important buttons, links, text and headings are present and clearly named.
- Build semantically: real
<button>and<a>elements, a logical heading hierarchy, form fields with<label for>. - Tidy up: hide elements that are not needed, label the ones that are (Tory Gray). Avoid duplicate entries, for example when alt text and the link text below it are identical.
- HTML first: content that only appears via JavaScript is in the rendered tree, but not in the delivered HTML that some agents read.
ChatGPT
Claude
Gemini
Perplexity
Google AI Mode