The Accessibility Tree Explained: How to Read, Test, and Fix Yours (2026)
Every page you publish exists twice.
There is the version your visitors see, the one with your brand colors, your spacing, your hero image. And there is a second, invisible version that the browser builds for software: a stripped-down map of what each element is and what it’s called. Screen readers read that second version. So do voice control tools, switch devices, automated test suites, and, increasingly, AI agents acting on your customers’ behalf.
That second version is the accessibility tree. When it’s accurate, assistive technology works. When it isn’t, your page can look flawless and still be unusable, and most of the WCAG failures you’d get flagged for in an audit are defects in this tree rather than in your design.
Here’s how it’s built, how to read it, and how to fix it.
- What Is the Accessibility Tree?
- The Four Properties of Every Node
- Accessibility Tree vs DOM: What's Actually Different
- What Gets Included and What Gets Removed
- How Accessible Names Are Computed
- How to Inspect the Accessibility Tree
- Most WCAG Failures Are Tree Defects
- Why the Tree Suddenly Matters More
- Five Mistakes That Break the Tree
- Keeping the Tree Healthy at Scale
- FAQs
What Is the Accessibility Tree?
The accessibility tree is a semantic representation of your page that the browser generates automatically. It contains no visual information , no colors, no fonts, no layout, only structure and meaning.
Browsers first parse your HTML into the DOM (Document Object Model), the in-memory model used to render the page and respond to JavaScript. From the DOM, the browser derives a second, simplified tree and exposes it through platform accessibility APIs so assistive technology can query it, read it aloud, and act on it.
The flow looks like this:
Your HTML → DOM tree → accessibility tree → platform accessibility API → assistive technology
The key word is derived. You never write the accessibility tree directly. You shape it through your choice of HTML elements, your labels, and any ARIA you add. Write <button>Submit</button> and the browser creates a node with the role “button” and the name “Submit,” with no further effort from you.
Build the same control out of a <div> and you get a node with no role and no name, and a screen reader user has no way to know it exists.
The Four Properties of Every Node
Each object in the tree carries a small set of properties. Get these right and assistive technology can describe and operate the element. Get them wrong and it can’t.
| Property | The Question It Answers | Example |
| Role | What kind of thing is this? | button, link, heading, checkbox, navigation |
| Name | What is it called? | “Add to cart”, “Search products” |
| State/Value | What condition is it in right now? | checked, expanded, disabled, “3 of 7” |
| Description | What extra context is there, beyond the name? | “Opens in a new window” |
Nodes also expose available actions, like a link can be followed or a text field can be typed into, which is what lets voice control software say “click Add to cart” and have it work.
A screen reader announcement is essentially these properties read in sequence. Consider two versions of the same visual control:
<!-- Exposed as: no role, no name. Effectively invisible. -->
<div class="btn" onclick="submitForm()">Send</div>
<!-- Exposed as: button, "Send". -->
<button type="submit">Send</button>
Copy
Both render identically. Only one exists in the accessibility tree as something a user can find and operate.
Accessibility Tree vs DOM: What’s Actually Different
This is the most common point of confusion, so it’s worth being precise. The accessibility tree isn’t a copy of the DOM. It’s a filtered, annotated interpretation of it.
| DOM Tree | Accessibility Tree | |
| Purpose | Every element, attribute, and text node | Conveying meaning to software |
| Contains | Rendering and scripting | Only nodes with semantic meaning |
| Layout divs and spans | Present | Pruned, or flattened to “generic” |
| CSS classes and IDs | Present | Absent |
| Decorative images | Present | Removed when marked decorative |
| Element ID | Whatever you tag | The computed role, which ARIA can override |
| Labels | Wherever you put them | Resolved into one computed accessible name |
Two consequences matter in practice.
First, the tree is usually far smaller than the DOM. A page with 1,400 elements might expose a few hundred meaningful nodes. Second, because roles are computed, ARIA can silently change what an element is. A <button role=”heading”> is exposed as a heading, and the button behavior users expect disappears from the tree even though the click handler still fires.
What Gets Included and What Gets Removed
Different hiding techniques have very different effects here, and mixing them up is the source of a surprising number of real bugs.
| Technique | Visible on screen? | In the accessibility tree? | Still focusable? | Use it for |
| display: none | No | No | No | Hiding content from everyone |
| visibility: hidden | No | No | No | Same, when you need to reserve layout space |
| hidden attribute | No | No | No | Semantic equivalent of display: none |
| aria-hidden=”true” | Yes | No | Yes | Decorative icons beside visible text |
| role=”presentation” / role=”none” | Yes | Element’s semantics removed, children still exposed | Yes | Stripping unwanted table or list semantics |
| Off-screen clipping (.sr-only) | No | Yes | Yes | Text for assistive technology only |
| opacity: 0 | Effectively no | Yes | Yes | Nothing — this is almost always a bug |
There are two areas where teams get hurt.
aria-hidden=”true” removes an element and all of its children from the tree, but changes nothing about focus. Put it on a focusable element and keyboard users can still tab to a control that assistive technology insists does not exist, which the ARIA specification explicitly warns against. Same story with opacity: 0: a control faded out for a transition stays in the tree and stays in the tab order until you also remove it properly.
One more subtlety worth knowing: removing an element from the tree doesn’t fully remove it from the experience. Text hidden with display: none can still supply an accessible name to another element via aria-labelledby. Absence from the tree is not the same as absence from the user’s experience.
How Accessible Names Are Computed
Since a missing name is the single most common tree defect, it’s worth knowing where names come from. Browsers follow the W3C’s Accessible Name and Description Computation, working down a priority order and stopping at the first source that yields text:
- aria-labelledby — references the ID of visible text elsewhere on the page. Wins over everything.
- aria-label — a string you supply directly.
- Native labelling — <label for>, the button’s own text content, alt on an image, <caption> on a table, <legend> in a fieldset.
- title attribute — a weak fallback, and unreliable on touch devices.
- placeholder — last resort on some inputs, and it disappears the moment the user types.
Two rules follow from that order. Prefer native labeling wherever it exists: it’s the most robust across browsers and screen readers, and it keeps the visible label and the accessible name in sync automatically. And never use aria-label to replace a visible label with different wording. WCAG 2.5.3 (Label in Name) requires that the accessible name contain the visible text, so voice control users can say what they see.
How to Inspect the Accessibility Tree
Every major browser exposes the tree. No extensions required.
Chrome. Right-click any element and choose Inspect. In the Elements panel, open the Accessibility pane beside Styles. You’ll see the computed role, the computed name and its source, ARIA attributes, and the node’s ancestors. For the whole page at once, enable the full-page accessibility tree in that pane, then use the toggle in the Elements panel to switch between the DOM view and the tree view. Selection stays in sync between them, which makes it easy to see how a given chunk of markup gets interpreted.
Edge. Same engine, same pane: Accessibility tab within the Elements tool.
Firefox. A dedicated Accessibility panel in DevTools, with a “Check for issues” dropdown that flags contrast, keyboard, and text-label problems as you browse the tree.
Safari. Select a node in the Elements tab and read the Node pane, which shows computed accessibility properties.
Two things to know before you rely on this, though.
What DevTools shows is the browser’s internal tree, which is not byte-for-byte what a screen reader receives. It includes generic and ignored nodes that never reach assistive technology. And a technically valid tree can still produce a terrible experience: correct roles in an illogical order, or twelve links all accurately named “Read more.”
DevTools tells you what software receives. Only testing with a real screen reader, and ideally with real assistive technology users, tells you whether the result makes sense.
Most WCAG Failures Are Tree Defects
Here’s the part that rarely gets said plainly. WebAIM’s February 2026 analysis of the top one million home pages found detectable WCAG 2 failures on 95.9% of them, up from 94.8% a year earlier, reversing six consecutive years of slow improvement. Errors averaged 56.1 per page, a 10.1% rise, while average page complexity jumped 22.5% in a single year to 1,437 elements.
Six failure categories account for 96% of everything detected. Look at what they actually are:
| WebAIM 2026 failure | % of Home pages | What it is in the tree | WCAG criterion |
| Low-contrast text | 83.9% | Not a tree defect — a CSS problem | 1.4.3 |
| Missing image alt text | 53.1% | Image node with no accessible name | 1.1.1 |
| Missing form input labels | 51.0% | Textbox node with an empty name | 1.3.1, 4.1.2 |
| Empty links | 46.3% | Link node with no accessible name | 2.4.4, 4.1.2 |
| Empty buttons | 30.6% | Button node with no accessible name | 4.1.2 |
| Missing document language | 13.5% | Wrong pronunciation for the whole tree | 3.1.1 |
Four of the six are the same defect wearing different clothes: a node in the accessibility tree that has no name. A screen reader reaching one of those nodes can tell the user something is there and that it can be clicked, but not what it does. Users are left guessing, or they leave.
That reframing is useful because it turns a long, unrelated-looking issue list into one habit: for every interactive element and every meaningful image, check that the tree shows a name. Most of your automated error count disappears with it. (Contrast is the honest exception. It never touches the tree, so pair this work with a contrast check.)
Why the Tree Suddenly Matters More
For twenty years, the accessibility tree was infrastructure for assistive technology. In 2026 it’s also the interface software uses to read the web generally.
Automated test frameworks query it directly. Playwright’s getByRole() locators resolve against the accessibility tree rather than CSS selectors, which is why role-based tests survive refactors that break div.card > button.btn.
AI browser agents have converged on the same approach: reading the tree instead of raw HTML or screenshots is dramatically cheaper in tokens and more reliable, so agent tooling increasingly works from tree snapshots. And Cloudflare’s measurements for the week of 30 May 2026 put automated traffic at 57.2% of requests for HTML content, against 42.8% human, a crossover their CEO had expected in 2027.
Some of that traffic is scraping you’d rather block. A growing share is agents acting for real people: comparing your prices, filling your forms, completing your checkout. Those agents encounter the same nameless buttons and unlabeled inputs your screen reader users do, and they fail in the same place.
This isn’t a reason to reframe accessibility as an AI optimization exercise. The legal obligations under the ADA, WCAG, and the EAA stand on their own, and disabled users were always the point. It is a reason the work is now easier to fund. The same fix serves both audiences, and there’s no version of this where a clean semantic tree costs you anything.
Five Mistakes That Break the Tree
- Divs standing in for controls. A <div> with a click handler has no role, no name, no keyboard support, and no presence in the tree. Use the native element. This is the single highest-leverage habit in semantic HTML.
- aria-hidden on something focusable. It hides the element from assistive technology while leaving it fully tabbable. If you truly need it gone, remove it from the tab order too, or hide it with display: none.
- ARIA overriding correct native semantics. Adding role to an element that already has the right one is at best redundant and at worst destroys it. The first rule of ARIA remains: don’t use ARIA if native HTML will do.
- Placeholders used as labels. A placeholder is a hint, not a name. It vanishes when the user types, leaving a nameless field. Use <label for>.
- Dynamic changes nobody is told about. In single-page apps, updating the DOM updates the tree, but nothing announces the change. Route changes, validation errors, and cart updates need live regions or managed focus, and they need testing on interactive states, not just on initial page load.
Keeping the Tree Healthy at Scale
One-off cleanups don’t hold.
What works is layered:
- Semantic HTML first. Native elements give you correct roles, names, and keyboard behavior for free.
- ARIA is for the gaps. Automate the name-and-role checks. Missing names, invalid roles, and broken ARIA references are exactly what machines catch reliably. Scheduled scanning with ACE™ Scanner keeps regressions from accumulating between audits, and SmartFix™ can resolve many markup-level defects at the code level rather than papering over them with an overlay.
- Test what automation can’t see. Reading order, whether a name is meaningful, whether a custom widget behaves as its role implies. tThose need a human with a screen reader, and periodically an expert audit.
Roughly a third of your work is conceptual and two-thirds is repetition. Automate the repetition and spend your human attention on the third that matters.
FAQs
Does aria-hidden="true" remove an element from the accessibility tree?
Yes, it removes the element and all of its children. But it does not remove them from the tab order, so never apply it to a focusable element.
Is an accessible name the same as a label?
Not quite. A label is one possible source; the accessible name is the single string the browser computes, following a priority order in which aria-labelledby outranks aria-label, which outranks native labelling.
Can automated tools test the accessibility tree?
Partly. Missing names, invalid roles, and broken ARIA references are reliably detectable. Whether a name is meaningful, whether the reading order makes sense, and whether a custom widget behaves as its role implies require manual testing.
Do AI agents use the accessibility tree?
Many do. Reading the tree is cheaper and more stable than parsing raw HTML or screenshots, so browser automation frameworks and AI agents commonly work from tree snapshots, meaning tree defects break them the same way they break screen readers.