How the Accessibility Tree Breaks AI Agents’ Site Scans

AI agents don’t experience your website the same way a human does. They bypass visual design, hero images, and brand colors entirely. Instead, they rely on the accessibility tree, a stripped-down structural model of the page that has powered screen readers for two decades. And now, the audience reading through that lens has become the majority.

Between May 30 and June 5, 2026, Cloudflare Radar recorded that 57.2% of HTTP requests to HTML content came from automated bots, compared to just 42.8% from humans. Cloudflare CEO Matthew Prince, who shared the data on June 3, had originally predicted that crossover would happen in 2027. He was wrong,by over a year.

Some of that automated traffic comes from scrapers you’d rather block. But a large and growing share represents AI agents reading pages on behalf of real users. And according to accessibility data published this year, the structure those agents depend on is getting worse for the first time in six years.

What the Accessibility Tree Is and Why It Matters

The accessibility tree is a semantic version of your page, built by the browser from the DOM so non-visual software can interpret it. The pipeline is straightforward: HTML becomes the DOM, which becomes the accessibility tree, which is consumed by assistive technology and, increasingly, by AI agents.

The W3C’s WAI-ARIA 1.2 defines it as a “tree of accessible objects that represents the structure of the user interface,” where each node “represents an element in the UI as exposed through the accessibility API.” The browser constructs it from the DOM, then exposes it via the operating system’s accessibility API, which, per the W3C, “can be used by any assistive technologies, such as screen readers.” MDN explains that browsers “create an accessibility tree based on the DOM tree.”

Crucially, the accessibility tree discards most of the DOM. A page with thousands of nodes collapses to the meaningful, interactive set: headings, links, buttons, form fields, landmarks, and images with their text alternatives. For software working within a limited context window, that reduction is what makes the tree usable at all.

Every node in the accessibility tree carries four properties:

• Role: What kind of element it is (button, navigation region, list item)The tree also records what can be done with a node: a link can be followed, a text input can be typed into. That is exactly the information an agent needs to act.

Why AI Agents Prefer the Accessibility Tree Over Pixels

Agents driving a browser can understand a page in three ways: read the raw HTML, analyze a screenshot with a vision model, or read the accessibility tree. The industry is split on which approach to use.

Some agents rely purely on the accessibility tree. Microsoft’s Playwright MCP, a widely used tool for letting a model operate a browser, “uses Playwright’s accessibility tree, not pixel-based input,” with “no vision models needed, operates purely on structured data.” Its tool description tells the model an accessibility snapshot “is better than screenshot.”

Others go vision-first. OpenAI’s Computer-Using Agent, the model behind Operator, works primarily from screenshots. It does not read your accessibility tree to decide what to click.

A third approach is hybrid: using the structured accessibility tree for the bulk of the page, plus vision for parts the tree cannot capture, like canvas-rendered apps and dense visual layouts.

Two forces push agents toward the accessibility tree:

• Cost: A screenshot spends a large number of tokens encoding a picture the model must then interpret. The accessibility tree is compact text.The clearest signal of where this is heading comes from the vendors themselves. OpenAI’s Publishers and Developers FAQ says ChatGPT Atlas “uses ARIA tags, the same labels and roles that support screen readers, to interpret page structure and interactive elements,” and advises that making a website more accessible helps the agent understand it. OpenAI, the company behind Computer-Using Agent, still recommends making websites more accessible. For the machine, accessibility and readability are the same problem.

Why a Markdown Copy Isn’t Enough

A clean markdown version of a page is a good way to feed an agent your content, and providers like Cloudflare now generate one at the edge. For reading, extracting, and citing, markdown is fine,often better than raw HTML.

But a markdown copy carries only the words. It cannot tell an agent that a control is a button, whether that button is disabled, or hand it something to click. It lets an agent read the page, but not operate it.

It also represents a separate copy of the page, which can tell an agent one thing while the rendered page shows humans something else. A hand-maintained copy drifts from the real markup over time. The accessibility tree has neither problem. The browser builds it from the same page it renders to people, so there is nothing extra to maintain and nothing to cloak. It carries the roles, states, and element references an agent needs to act. For an agent that has to do something, one of these approaches is close to pointless, and the other is the whole point.

How to See Your Own Accessibility Tree

Every major browser shows you the exact tree an agent reads. In Chrome, open DevTools, select an element in the Elements panel, and open the Accessibility tab to see that element’s computed role, name, and state. To view the whole page the way the tree does, turn on the “Show accessibility tree” toggle, which “replaces the DOM tree in the Elements panel with a full-page accessibility tree.”

For the same thing in code, Playwright’s ARIA snapshots produce “a YAML representation of the accessibility tree of a page,” capturing roles, accessible names, states, and nesting. Running an ARIA snapshot against your own URL returns almost exactly the structured text an agent like Playwright MCP receives.

Here is an easy test: For every important action on the page, does the tree show a node with the right role and a clear name? A “buy” button that appears in the tree as a generic element with no accessible name is a button your customers’ agents can see but cannot confidently use. Run this on a few pages, and the gaps will show up fast.

The 2026 Data: The Web Is Getting Harder for Machines to Read

The accessibility tree is only as good as the markup it is built from. In 2026, that markup got worse. Web accessibility regressed for the first time in six years, at the same moment agents became the majority of HTML traffic.

The WebAIM Million, the annual automated analysis of the top 1 million home pages, reported in its February 2026 edition:

• 95.9% of home pages had detectable WCAG failures, up from 94.8% the year before, which WebAIM describes as “reversing a trend of small improvements each of the previous 6 years.”A 22.5% jump in page complexity in a single year is not normal. More elements mean more places for structure to break, and the report shows exactly where it breaks.

The Most Common Failures Blank Out the Accessibility Tree

The accessibility failures WebAIM finds most often are exactly the defects that strip meaning out of the tree an agent reads:

• Low-contrast text: 83.9% of home pages affected. A visual failure for low-vision users and vision-based agents.Nearly half of the top million home pages come with empty links. Almost a third have empty buttons. For the visitor class that now outnumbers humans, those are dead ends. As the report states: “Addressing just these few types of issues would significantly improve accessibility across the web.”What WebAIM has measured every year for screen-reader users is the same thing that decides whether an AI agent can read and act on your page. Different audiences, identical broken structure.

WebAIM Ties Rising Complexity to Frameworks and “Vibe Coding”

WebAIM attributes the rising complexity to “increased reliance on 3rd party frameworks and libraries and automated or AI-assisted coding practices (‘vibe coding’).”

This is the first WebAIM Million published well into the era of generating production websites by prompting a model. More code, shipped by more people, more pages deployed faster, more complexity stacked on complexity, with fewer humans in the loop asking whether an element needs to exist or whether a control exposes its name and role.

There is no way to prove a single cause for a one-year reversal across a million websites. But the timing is impossible to ignore, and the contradiction is the point: Humans are using AI to build a web that AI itself cannot reliably consume. Bloated DOMs, broken semantics, unnamed controls. The same defects that hurt humans and screen readers hurt the crawlers and the agents.

It is tempting to think you should not worry, because the next model will be good enough to sort out the mess. That is a marketing line, not a strategy. The same products promising the model will handle anything also tell you, in fine print, that the assistant can make mistakes.

Independent measurements like the WebAIM Million are among the only objective signals we have about what is really happening to the web underneath that promise. Right now, the signal is that the web is getting harder to parse at the exact moment more of its traffic depends on parsing it cleanly.

The ARIA Paradox: Bolting On Attributes Makes It Worse

More ARIA correlates with more errors, not fewer. WebAIM found that home pages with ARIA present averaged 59.1 errors, against 42 on pages without it.

ARIA (Accessible Rich Internet Applications) is a set of attributes you add to HTML to hand the accessibility tree the roles, names, and states the native markup did not supply. The reason for the paradox is simple: An empty or wrong attribute does not leave the accessibility tree blank. It fills the tree with confident, possibly incorrect information, which is worse for an agent than an honest gap, because the agent has no way to know it is being misled.

This is where the vendors and the standards body disagree:

• OpenAI tells developers to add ARIA roles, labels, and states so agents understand a page.The WebAIM data sides with the specialists: The pages reaching hardest for ARIA carry the most errors. You do not fix the accessibility tree by adding attributes. You fix it by making the underlying markup mean what it says, reserving ARIA for the genuine gaps native HTML cannot express.

Make the Markup Mean What It Says

The fixes are unglamorous and well understood, and they pay off twice: once for the humans using assistive technology, once for the agents that are now the majority of your traffic.

• Use native HTML for native behavior. A “ is a button in the tree with no extra work. A “ with a click handler is an unnamed, roleless node an agent cannot trust. The same holds for “ and “.It is not too late to start, and none of this requires a redesign. The accessibility debt on most websites is real and years deep, and the 2026 numbers show it growing rather than shrinking. But the fixes are still small: markup-level changes you can make page by page, not a full rebuild that would take months. Start with your highest-traffic pages, check the accessibility tree, and fix the empty controls and unlabeled inputs first. Every one of these fixes serves a human visitor and a machine visitor in the same change.Accessibility used to be a compliance checkbox, something reached after the redesign was launched. It is now the interface the majority of your visitors use to read your website. Teams that build their markup to mean what it says will be legible to the agents deciding what to recommend and what to buy. Teams betting that a future model will clean up the mess are wagering on someone else’s questionable roadmap. The web has now handed us a year of data on how that bet is going.At the same time, interest in web accessibility is at a five-year high. It was flat for years, then climbed through 2025 and spiked in 2026. The drivers are mixed: compliance deadlines like the ADA Title II web rule and the European Accessibility Act, a rising wave of accessibility lawsuits, and broader attention as AI changes how the web is built and read. No single one explains the whole curve, and claiming it does would be a guess.But the direction is the whole point. The attention is arriving, the fixes are manageable, and the audience that depends on them is now the majority. The moment to fix the web is now.