Accessibility Tree and AI Agents – How to Optimize Yours

If your website’s accessibility tree is broken, AI agents have a hard time doing their job.

A 2026 study by UC Berkeley and the University of Michigan found that task success dropped from 78% to 42% when agents navigated websites with a degraded accessibility tree. Nearly half of all tasks failed simply because the structural information the agent needed was not there.

In this guide, we cover what the accessibility tree is and how AI agents use it. We then look at what breaks it, how to inspect it, and how to fix it.

What is an accessibility tree?

The accessibility tree is a simplified version of your webpage that the browser builds automatically for assistive technologies, especially screen readers.

It contains no visual information. No styles, no layout, no colors.

Just the elements that matter for interaction: buttons, links, form fields, headings, and landmarks. Each element is described by its role, name, and state.

It is built so that people who cannot use a mouse or see the screen can still navigate and interact with your website. A screen reader queries the tree and reads out what is on the page. A keyboard user navigates through it element by element.

How AI agents use the accessibility tree

An AI agent is essentially blind. They do not see your page. It navigates your site the same way a blind user does with a screen reader and keyboard.

Styles, colors, and visual layout mean nothing.

When an agent loads your webpage, it requests the accessibility tree. The tree comes back as structured text: a list of elements, each tagged with a role, a name, and a state. The agent scans that list, identifies what it can interact with, and issues commands.

Say a user asks their agent to book a flight. The agent lands on your website, reads the accessibility tree, and looks for an input field labeled “From” and another labeled “To.” It fills them in, finds a button named “Search flights,” and clicks it.

Every step depends on the tree having the right names and roles. If a label is missing or a role is wrong, the agent has to find other ways to complete the task. That results in more time and more tokens spent on a task that should have been straightforward.

How AI agents see your website

AI agents have three ways to perceive a webpage:

• Read the accessibility tree
• Parse the raw HTML
• Take a screenshot and analyze the pixels

The method an agent uses determines how fast it works, how much it costs to run, and how reliably it completes tasks on your site.

Accessibility tree parsing is the cleanest input and the agent’s first choice. The browser has already stripped the decorative nodes and tagged every meaningful element with a role, name, and state. The processing cost is low.

Raw DOM parsing is the fallback when the accessibility tree is incomplete or broken. The full HTML includes scripts, styles, inline event handlers, and structural markup that have nothing to do with what a user can interact with. The agent has to filter all of that out before it can reason over the page. Processing cost is medium.

Screenshot mode is the last resort. The agent takes a visual capture of the page and identifies elements by analyzing pixels. It requires no knowledge of HTML, but the processing cost is very high.

Most production agents use a hybrid approach, starting with the accessibility tree and falling back as needed. A broken accessibility tree forces that fallback more often.

	Screenshot	Raw DOM Parsing	Accessibility Tree
What the agent receives	A pixel image of the rendered page. Elements are identified by visual position and appearance.	The full HTML source, including scripts, styles, inline handlers, and structural markup.	A stripped, structured map of every meaningful element, each tagged with role, name, and state.
Token cost	Very high	Medium	Low
Speed	Slow. Each action requires capturing, sending, and analyzing a new image.	Faster than screenshots, but the agent must filter noise before reasoning.	Fast. The browser has already done the filtering work.
Reliability	Works on anything rendered visually, including canvas, WebGL, and legacy portals.	Fragile on dynamic pages where the DOM changes after JavaScript executes.	The most consistent input for task completion. Playwright MCP defaults to accessibility tree snapshots.
When agents use it	When the accessibility tree is broken or absent, or elements exist only as pixels.	When the accessibility tree is unavailable and a screenshot is too expensive.	Preferred method. Falls back when the tree is incomplete due to unsemantic HTML or missing ARIA.

What happens when your accessibility tree is broken

When the accessibility tree is broken, the agent falls back to raw DOM parsing.

The full HTML is noisier and more expensive to process, but it works for simpler pages. Processing cost moves from low to medium.

If DOM parsing also fails, the agent has one option left: screenshot mode. The potential cost would be very high. A token-conscious agent may not justify that cost and will abandon your site. Others will push through, but at a significantly higher cost.

The potential cost would be very high. For agents operating within a token budget, that cost may not be justifiable. The agent abandons your site and moves to another website. That said, this would not always be the case. Some agents will push through regardless of cost.

A broken accessibility tree increases the time and tokens an agent spends on your site. In the worst case, the agent abandons it altogether, and your site loses the lead or conversion.

What breaks your accessibility tree

Your accessibility tree can break in two ways, and each one affects AI agents differently.

#1. Sparse tree

A sparse tree happens when your site is built without semantic HTML. Using <div> and <span> instead of native elements like <button>, <nav>, and <input> means very few elements get added to the tree. The agent finds almost nothing to interact with and cannot complete tasks.

#2. Missing or inaccessible values

Missing or inaccessible values happen when the tree exists, but the information inside it is incomplete. Elements appear in the tree, but their name is blank, their role is wrong, or their label is meaningless. The agent finds the element but cannot identify what it is or what to do with it.

How to inspect your accessibility tree

Your browser already has everything you need to inspect the accessibility tree.

Here is how to do it in Chrome:

1. Open Chrome and navigate to the page you want to inspect.
2. Right-click any element and select Inspect, or press F12.
3. Click the accessibility icon in the top-right of the Elements panel.
4. Select the element you want to examine.
5. The right pane shows three things: the element’s name, its role, and its computed properties.

What to look for

Once you’re in the tree, these are the problems that matter most for AI agent navigation:

• Interactive elements with no accessible name. A button or link with no accessible name is invisible to agents. They can find the element, but cannot identify what it does.
• Incorrect roles. An element given the wrong ARIA role appears in the tree but gives agents false information. A navigation landmark marked as role=”main” is one example.
• Icon-only buttons. If the only label is a visual icon and no aria-label is set, the name field is empty. The agent finds the button but cannot identify what it does.
• Form inputs without labels. An unlabeled input has no name in the tree. An agent cannot identify what the field is for and cannot fill it reliably.
• Links with non-descriptive names. A link labelled “read more” or “click here” has a name, but it is meaningless. An agent cannot tell where it leads or what action it performs.
• Missing landmark structure. Without <main>, <nav>, and <header>, the agent can find individual elements but cannot understand the overall layout of the page.

Going through every element manually is time-consuming and easy to miss.

WebYes Accessibility can make your life easy here. The tool runs all of these checks automatically across every page on your site in one go.

How to fix a broken accessibility tree

The fix for a broken accessibility tree starts with semantic HTML.

Use native elements wherever possible. A <button> is always better than a <div> with a click handler. A <nav> is always better than a <div class=”nav”>. Native elements populate the accessibility tree automatically with the correct role, name, and state.

When native HTML cannot do the job, use ARIA.

Custom components, dynamic widgets, and complex interactions sometimes need ARIA roles and attributes to fill the gaps. Keep it targeted. ARIA should correct or extend the tree, not replace what semantic HTML would have handled on its own.

While you are at it, implement structured data for AI agents as well. A clean accessibility tree tells AI agents how to navigate your site. Structured data tells them what your content means. Together, they make your website more AI agent-friendly.

FAQs