How AI Agents See Your Website: The Accessibility Tree Explained

51% of all web traffic is now automated (Imperva Bad Bot Report 2025). Bots, crawlers, and increasingly AI agents navigate the web on behalf of users. Browser agents may combine the DOM, accessibility tree, and screenshots, with different tradeoffs for structure, visual context, and token cost.

The accessibility tree is an important structured representation for browser agents and assistive technology. Understanding how it works, which frameworks expose it, and where DOM or screenshot context complements it is now a key part of AI agent readiness .

How AI Agents Actually See Your Website

Browser agents can use three representations to understand a page, often combining them. Each has real tradeoffs in accuracy, speed, and token cost:

Accessibility snapshots are a common structured interface in frameworks such as Playwright MCP and agent-browser. The full DOM contains every div, span, style, and script tag, while the accessibility tree focuses on interactive elements, labels, states, and relationships. Screenshots add layout and visual context that neither tree provides on its own.

What Is the Accessibility Tree? A Technical Breakdown

The accessibility tree is a simplified representation of the DOM that browsers automatically generate from your HTML. Originally designed to expose page structure to assistive technologies like screen readers, it gives compatible browser-agent frameworks a concise view of roles, names, states, and relationships.

Every node in the accessibility tree has four core properties:

To see this in practice, here's how the DOM and the accessibility tree represent the same login form:

DOM vs Accessibility Tree: A Comparison

<!-- What the DOM sees: 47 nodes, deeply nested -->
<div class="flex flex-col gap-4 p-6 bg-white rounded-xl shadow-lg
            border border-gray-200 max-w-md mx-auto">
  <div class="text-center mb-2">
    <h2 class="text-2xl font-bold text-gray-900">Welcome back</h2>
    <p class="text-sm text-gray-500 mt-1">Sign in to your account</p>
  </div>
  <div class="space-y-4">
    <div class="relative">
      <label class="block text-sm font-medium text-gray-700 mb-1"
             for="email">Email</label>
      <input type="email" id="email" name="email" required
             class="w-full px-3 py-2 border border-gray-300 rounded-lg
                    focus:ring-2 focus:ring-blue-500 focus:border-blue-500
                    placeholder-gray-400"
             placeholder="you@example.com" />
    </div>
    <div class="relative">
      <label class="block text-sm font-medium text-gray-700 mb-1"
             for="password">Password</label>
      <input type="password" id="password" name="password" required
             class="w-full px-3 py-2 border border-gray-300 rounded-lg" />
    </div>
    <button type="submit"
            class="w-full py-2 px-4 bg-blue-600 hover:bg-blue-700
                   text-white font-medium rounded-lg transition-colors">
      Sign in
    </button>
  </div>
</div>

# What the accessibility tree sees: 5 meaningful nodes
- heading "Welcome back" level=2
- textbox "Email" required focused
- textbox "Password" required
- button "Sign in"
- text "Sign in to your account"

47 nodes of styling classes, layout divs, and visual attributes in the DOM. Five nodes in the accessibility tree. That's the information an agent needs to fill in credentials and submit the form. This is why accessibility tree parsing is 93% more token-efficient than raw DOM parsing in this example. Frameworks that expose accessibility snapshots can use that compact structure for interaction, while DOM and screenshot context remain useful for other tasks.

You can inspect the accessibility tree yourself in Chrome DevTools: open the Elements panel, find the "Accessibility" tab in the sidebar, and you'll see the computed accessibility properties for any element. This is one important representation browser agents may combine with the DOM and screenshots.

Which AI Agent Frameworks Use the Accessibility Tree?

Accessibility-tree support is not theoretical. The following frameworks expose it directly or combine it with other modalities:

These examples show why semantic structure matters, even when an agent also uses DOM data or visual rendering. For a deeper look at how these agent protocols work, see our guide on the Model Context Protocol (MCP) .

Here's what a Playwright MCP accessibility snapshot actually looks like for a navigation menu:

# Playwright MCP browser_snapshot output
- navigation "Main":
  - link "Home" (ref=1)
  - link "Products" (ref=2)
    - link "Enterprise" (ref=3)
    - link "Startup" (ref=4)
  - link "Pricing" (ref=5)
  - link "Documentation" (ref=6)
  - link "Contact Sales" (ref=7)
- main:
  - heading "Build faster with AI" level=1
  - text "Deploy intelligent agents that understand your codebase"
  - link "Get Started Free" (ref=8)
  - link "View Demo" (ref=9)

Each element has a semantic role, a human-readable name, and a reference number. The agent says "click ref 8" to click the "Get Started Free" link. No CSS selectors, no pixel coordinates, no visual parsing needed. Clean, efficient, and reliable.

The Research: Accessible = Better AI Performance

Academic research confirms what the frameworks are showing us. Websites that follow accessibility best practices produce dramatically better results for AI agents. The most comprehensive evidence comes from the CHI 2026 study "Is the Web Accessible for AI Agents?", which systematically tested how accessibility barriers affect agent performance.

When AI agents have access to a fully accessible page with proper semantic structure, they succeed 78.33% of the time. Force them through accessibility barriers like keyboard-only navigation without visible focus indicators, or magnified views that hide context, and performance drops by nearly half or more. The same barriers that prevent disabled users from using your site also prevent AI agents from completing tasks.

The broader benchmark landscape tells a similar story. AI agent performance on web tasks has improved rapidly, but the gains concentrate on well-structured, accessible websites:

The CHI 2026 researchers identified three categories of failure when agents encounter inaccessible pages:

The WCAG–AI Agent Readiness Overlap

The connection between web accessibility (WCAG) and AI agent readiness isn't a coincidence. It's structural. Screen readers depend on accessibility information, and compatible browser-agent frameworks can use the same semantic signals. Here's how the mapping works:

As Jason Taylor, Chief Accessibility Innovation Strategist at UsableNet, puts it: "Optimizing for accessibility is like optimizing for AI agents — same tree, same rules." The accessibility tree is essential to screen readers and an important structured signal for compatible browser agents. Improving accessibility can therefore improve those agents' semantic interactions too.

Our scanner measures exactly these overlapping signals. Every checkpoint in our Content & Semantics category maps directly to a WCAG success criterion. The same structural quality that enables accessibility enables AI comprehension.

The ARIA Controversy: Use With Caution

Because some browser-agent frameworks use accessibility snapshots, you might think the answer is to add ARIA attributes everywhere. Several prominent AI voices, including OpenAI, have suggested that developers should add aria-label attributes to improve agent understanding. The accessibility community has a strong counter-message: most ARIA usage on the web today is harmful, not helpful.

According to WebAIM's annual Million analysis, pages that use ARIA attributes average 57 accessibility errors, compared to just 27 errors on pages without any ARIA. More than double. ARIA is overwhelmingly misused, added as a band-aid over non-semantic markup rather than as a genuine enhancement to well-structured HTML.

Accessibility expert Adrian Roselli has been particularly vocal about this: OpenAI's own guidance encouraging developers to add ARIA labels contradicts the first rule of ARIA, which states: "If you can use a native HTML element or attribute 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."

The right approach for both accessibility and AI agent readiness:

1. Use semantic HTML first — <button> instead of <div onclick>, <nav> instead of <div class="nav">
2. Add ARIA only when HTML falls short, for custom widgets, dynamic content regions, or complex interaction patterns
3. Test your accessibility tree, verify that what the browser generates matches what you intend agents and screen readers to see
4. Never use ARIA to override correct HTML semantics. A <button role="link"> confuses both screen readers and agents

Here's a concrete example of the right and wrong approach:

<!-- WRONG: div soup with ARIA band-aids -->
<div role="navigation" aria-label="Main navigation">
  <div role="list">
    <div role="listitem">
      <div role="link" tabindex="0" aria-label="Home"
           onclick="navigate('/')">Home</div>
    </div>
    <div role="listitem">
      <div role="link" tabindex="0" aria-label="Products"
           onclick="navigate('/products')">Products</div>
    </div>
  </div>
</div>

<!-- RIGHT: semantic HTML that needs zero ARIA -->
<nav aria-label="Main navigation">
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/products">Products</a></li>
  </ul>
</nav>

The semantic version is shorter, produces a cleaner accessibility tree, works with keyboard navigation by default, and requires zero ARIA. AI agents can parse it instantly. The div-soup version requires 10 ARIA attributes to achieve the same result. Poorly.

The Business Case: 95% of Websites Are Failing

Because accessibility snapshots are one important browser-agent signal, widespread accessibility failures also weaken that interaction path. And the numbers are sobering.

WebAIM's 2025 Million analysis found that 94.8% of the top 1,000,000 websites have detectable WCAG failures. The average page has 51 errors. But here's where it gets interesting: 96% of all detected errors fall into just six categories:

1. Low contrast text (81% of pages) — doesn't directly affect AI agents but signals poor attention to standards
2. Missing alt text (54.5%) makes image meaning less reliable across non-visual and structured representations
3. Missing form labels (45.9%) makes form fields ambiguous in accessibility snapshots
4. Empty links (44.6%) makes links hard to identify by role and name
5. Empty buttons (28.1%) removes the programmatic name used by semantic interaction tools
6. Missing document language (17.1%) — agents may process content with the wrong language model

Five of these six issues directly degrade the accessibility tree used by snapshot-dependent browser agents. Fixing them doesn't require a redesign. Add alt text, label forms, name links and buttons, set a language attribute. These are quick, measurable improvements for accessibility and semantic agent interaction.

The opportunity is clear. Accessibility improvements strengthen semantic interaction for compatible browser agents without proving overall AI agent readiness. Sites that address these barriers provide better structured signals to snapshot-dependent agents, while broader readiness still depends on factors such as rendered DOM access, visual context, content quality, and agent protocols.

Practical Checklist: Making Your Site AI-Agent-Accessible

Based on the research, framework requirements, and accessibility data, here's a three-tier approach to improving how AI agents see your site:

Tier 1: Quick Wins (Fix the Six Most Common Issues)

Tier 2: Structural Improvements

Tier 3: Advanced AI Agent Optimization

For detailed implementation guides on the advanced tier, see our posts on WebMCP , agents.json , and the Google A2A protocol .

Conclusion: One Tree, Two Audiences

The accessibility tree was designed to make the web usable for people with disabilities. It now also gives compatible browser-agent frameworks a structured, semantic representation of page content and available actions. Other agents may combine it with the DOM and screenshots.

This overlap means that investments in web accessibility also improve the semantic signals available to compatible browser-agent frameworks. Semantic HTML, proper heading hierarchy, labeled forms, descriptive links, and ARIA where needed strengthen accessibility snapshots, alongside DOM and screenshot context.

With 94.8% of websites showing detectable accessibility failures, improving the accessibility tree is a concrete way to support users with disabilities and snapshot-dependent browser agents. It does not guarantee recommendations, citations, transactions, or overall agent readiness, but it removes avoidable semantic interaction barriers.

Sources

• Imperva 2025 Bad Bot Report — 51% of web traffic is now automated
• "Is the Web Accessible for AI Agents?" — CHI 2026 Study — Systematic testing of accessibility barriers on AI agent performance
• WebAIM Million 2025 — Annual Accessibility Analysis — 94.8% of top 1M sites have WCAG failures, 51 average errors per page
• browser-use — AI Agent Browser Automation Framework — 89.1% WebVoyager score with accessibility snapshot approach
• Anthropic Computer Use — Claude Web Navigation — read_page tool using accessibility tree extraction
• Playwright MCP — Microsoft's Accessibility-First Browser Automation — YAML accessibility snapshots as default page representation
• Google Project Mariner — AI Web Agent — 83.5% WebVoyager using hybrid vision + accessibility tree
• WebArena: A Realistic Web Environment for Building Autonomous Agents — Benchmark showing progression from 14% to 62%+ success
• Adrian Roselli — OpenAI and Accessibility — Criticism of ARIA overuse guidance from AI companies
• W3C: Using ARIA — First Rule of ARIA — "If you can use a native HTML element… then do so"
• IsAgentReady: What Is AI Agent Readiness?
• IsAgentReady: SEO vs AEO — How Traditional Search Differs from AI Optimization
• IsAgentReady: What Is MCP? The Model Context Protocol for AI Agents
• IsAgentReady: What Is WebMCP and Why Your Website Needs It
• IsAgentReady: What Is agents.json? Advertising AI Agent Capabilities
• IsAgentReady: What Is Google A2A? Agent-to-Agent Communication Protocol