The Accessibility Tree Is How AI Agents Read Your Site & It’s Breaking via @sejournal, @slobodanmanic

AI agents do not read your website the way you do. They do not see your layout, your hero image, or your brand color. They prefer reading the accessibility tree: a stripped-down structural model of the page, the same one that has powered screen readers for two decades.

Today, that matters more because the audience reading that way is now the majority.

For the week of May 30 to June 5, 2026, Cloudflare Radar measured 57.2% of HTTP requests to HTML content, the requests that represent web-page traffic, as automated bots, against 42.8% human. Cloudflare CEO Matthew Prince, who shared the data on June 3, had forecast that crossover for 2027. He got it wrong because it arrived over a year early.

Cloudflare Radar, Bot vs. Human distribution filtered to HTML content (web-page traffic), May 30 to June 5, 2026 (Image from Cloudflare Radar by author, June 2026)

Some of that automated traffic is scrapers you probably want gone. A large and rising share is AI agents reading pages for real people. And according to the accessibility data published this year, the structure those AI agents depend on is getting worse, for the first time in six years.

The Accessibility Tree Is A Structural Model The Browser Builds From Your DOM

The accessibility tree is a semantic version of your page that the browser computes from the DOM so non-visual software can understand it. The pipeline is short: HTML to DOM to accessibility tree to consumers (assistive technology, and now 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 builds it from the DOM (the mapping is specified in Core-AAM 1.2) and exposes it through the operating system’s accessibility API, which, per the W3C, “can be used by any assistive technologies, such as screen readers.” MDN explains the pipeline this way: Browsers “create an accessibility tree based on the DOM tree.”

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

Every node in the accessibility tree carries four properties:

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 in order to act.

AI Agents Read The Accessibility Tree Because It Costs Less And Misleads Less Than Pixels

An agent driving a browser can understand a page three ways: read the raw HTML, look at a screenshot with a vision model, or read the accessibility tree. There is a real split in how today’s agents do it.

Purely relying 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.” Vision-first. OpenAI’s Computer-Using Agent, the model behind Operator, works primarily from screenshots. It is not reading your accessibility tree to decide what to click. Hybrid. A third approach combines both: the structured accessibility tree for the bulk of the page, plus vision for the 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 then has to interpret. The accessibility tree is compact text. Reliability. A vision model has to guess which pixels form a clickable control. The tree states this outright, with a role and a name for each.

The clearest signal of where this goes is the vendors’ own guidance. 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’s Publishers and Developers FAQ (Image by author, June 2026)

OpenAI is the company behind Computer-Using Agent, the one that works by analyzing screenshots. They still recommend making websites more accessible. For the machine, accessibility and readability are the same problem. The full agent-by-agent breakdown is in a companion article on how AI agents see your website.

A Markdown Copy Is Not An Agent-Ready Page

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, and 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, not operate it.

It is also a separate copy of the page, and a separate copy can tell an agent one thing while the rendered page shows humans something else. A hand-maintained one also 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, and it carries the roles, states, and element references an agent needs to act. Which is why, for an agent that has to do something, one of the two is close to pointless, and the other is the whole point.

You Can See Your Own Accessibility Tree In About 2 Minutes

Every major browser shows you the exact tree an agent reads.

In Chrome, per the official DevTools accessibility documentation:

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’s an easy test you can run: 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 of your own pages, and the gaps will show up fast.

The 2026 Data Says The Web Is Getting Harder, Not Easier, 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.” 56.1 detected errors per home page, a 10.1% increase over the 51 found in 2025. 1,437 elements per home page, which WebAIM flags as “a 22.5% increase in only one year.”

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 Are The Ones That 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.

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. To quote the report:

“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. They’re different audiences with identical broken structure.

WebAIM Ties The 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. We have 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, and claiming one with certainty would be dishonest. 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’s 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, short for 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 on its own.

The reason 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 W3C’s First Rule of ARIA (first!) puts native HTML first: “If you can use a native HTML element … with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.” Accessibility specialists have pushed back on the vendor framing directly. W3C contributor Adrian Roselli, responding to OpenAI’s guidance, argued it inverts the discipline, pointing teams toward bolt-on attributes when the durable fix is correct native markup.

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 … fixing it. By making the underlying markup mean what it says, and 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 <button> is a button in the tree with no extra work. A <div> with a click handler is an unnamed, roleless node an agent cannot trust. The same holds for <a href> and <select>. Name every control. Use a real <label> on every form input. Accessible text on every link and button, including the icon-only ones. Empty links and empty buttons are the failures an agent hits first. Server-render the content that matters. A price, a spec, or a primary action that only appears after client-side JavaScript runs may never reach the tree an agent reads. Use ARIA for genuine gaps, not as a patch. Correct semantics first, attributes second, and only where native HTML cannot express the state. Remember the First Rule of ARIA? Inspect the result. Run your key pages through the DevTools accessibility tree or a Playwright ARIA snapshot, and confirm every important action shows up with a clear role and name.

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; the thing 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, the interest in web accessibility is at a five-year high.

Google Trends: worldwide search interest in “web accessibility,” past five years (Image by author, June 2026)

The interest was flat for years, then climbed through 2025 and spiked in 2026. The drivers are mixed, and worth being honest about: 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.

More Resources:

How AI Agents See Your Website (And How To Build For Them) Google Tells Developers To Build For AI Agents, Not Just Humans What Google’s New AI Guide Actually Debunks. And What It Doesn’t

---

Featured Image: Collagery/Shutterstock