How AI agents can use your website's accessibility tree

The accessibility tree is a browser-generated view of a page's semantic structure. It exposes roles and accessible names for elements such as buttons and form fields, helping compatible agents identify what they can interact with.

Browser agents may combine the DOM, accessibility tree, and screenshots. The tree is especially useful for snapshot-dependent browser agents; other agents also use visual context. It is one part of AI agent readiness , and a readable tree alone does not prove task success.

How AI agents see your website

Browser agents can use three representations to understand a page, and they often combine them. Each one trades off accuracy, speed, and token cost differently:

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:

The DOM and the accessibility tree represent the same login form in very different ways:

DOM vs accessibility tree

<!-- 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"

The DOM version has 47 nodes of styling classes, layout divs, and visual attributes. The accessibility tree has five nodes, and they hold the information an agent needs to enter credentials and submit the form. In this example, accessibility tree parsing is 93% more token-efficient than raw DOM parsing. Frameworks that expose accessibility snapshots can use that compact structure for interaction, while DOM and screenshot context remain useful for other tasks.

To inspect the accessibility tree yourself, open Chrome DevTools, go to the Elements panel, and select the "Accessibility" tab in the sidebar. It shows the computed accessibility properties for any element. Browser agents may combine this representation with the DOM and screenshots.

Which AI agent frameworks use the accessibility tree?

These frameworks expose the accessibility tree directly or combine it with other inputs:

Semantic structure matters even when an agent also uses DOM data or visual rendering. Our guide to the Model Context Protocol (MCP) explains how these agent protocols work.

A Playwright MCP accessibility snapshot of a navigation menu looks like this:

# 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. To click the "Get Started Free" link, the agent says "click ref 8". It needs no CSS selectors or pixel coordinates.

The research: accessibility and AI agent performance

The CHI 2026 study "Is the Web Accessible for AI Agents?" tested how accessibility barriers affect agent performance. Agents completed far fewer tasks under keyboard-only and magnified views than under the standard view.

On a fully accessible page with proper semantic structure, the agents in the study succeeded 78.33% of the time. With keyboard-only navigation and no visible focus indicators, the rate fell to 41.67%. With magnified views that hide context, it fell to 28.33%. The barriers that keep disabled users out of a site also stopped these agents from completing tasks.

Benchmark scores for web tasks have also risen quickly:

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

WCAG and AI agent readiness overlap

Web accessibility (WCAG) and AI agent readiness overlap because screen readers and compatible browser-agent frameworks can use the same semantic signals. The table maps each practice to its WCAG criterion, its benefit for agents, and the scanner checkpoint that covers it:

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 a subset of these overlapping signals. Checkpoints in our Content & Semantics category inspect published markup such as landmarks, labels, headings, alt text, language attributes, and link text. They do not run a browser agent or measure task comprehension.

The ARIA controversy: use it with caution

Because some browser-agent frameworks use accessibility snapshots, adding ARIA attributes everywhere can look like the answer. OpenAI has suggested that developers add aria-label attributes to improve agent understanding. Accessibility experts disagree, and WebAIM data shows why: pages that use ARIA have more detectable errors than pages without it.

WebAIM's annual Million analysis found that pages using ARIA attributes average 57 accessibility errors, against 27 errors on pages without ARIA. That is more than double. ARIA is often added to patch non-semantic markup instead of improving well-structured HTML.

Accessibility expert Adrian Roselli argues that OpenAI's guidance to add ARIA labels contradicts the first rule of ARIA: "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."

For both accessibility and AI agent readiness, follow these steps:

1. Use semantic HTML first. Write <button> instead of <div onclick> and <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 to 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"> can confuse both screen readers and agents

The two snippets below show a wrong and a right 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 needs no ARIA roles. It exposes clearer roles and names to tools that read the accessibility tree. The scanner checks parts of the underlying markup, but does not run a browser agent against either example.

The business case: 95% of top websites have WCAG failures

Accessibility snapshots are one important browser-agent signal, so widespread accessibility failures weaken that interaction path.

WebAIM's 2025 Million analysis found that 94.8% of the top 1,000,000 websites have detectable WCAG failures, and the average page has 51 errors. 96% of all detected errors fall into six categories:

1. Low contrast text (81% of pages) does not directly affect AI agents
2. Missing alt text (54.5%) makes image meaning less reliable across non-visual and structured representations
3. Missing form labels (45.9%) make form fields ambiguous in accessibility snapshots
4. Empty links (44.6%) make links hard to identify by role and name
5. Empty buttons (28.1%) remove the programmatic name used by semantic interaction tools
6. Missing document language (17.1%) means agents may process content in the wrong language

Five of these six issues degrade the accessibility tree that snapshot-dependent browser agents use. Fixing them does not require a redesign: add alt text, label forms, name links and buttons, and set a language attribute. Each fix is a small markup change that you can measure.

Accessibility improvements strengthen semantic interaction for compatible browser agents, but they do not prove overall AI agent readiness. Sites that fix these issues give snapshot-dependent agents better structured signals. Broader readiness also depends on rendered DOM access, visual context, content quality, and agent protocols.

Practical checklist: making your site accessible to AI agents

The checklist has three tiers, ordered from the most common issues to advanced work:

Tier 1: quick wins (the most common issues)

Tier 2: structural improvements

Tier 3: advanced AI agent optimization

Our posts on WebMCP , agents.json , and the Google A2A protocol cover the advanced tier in detail.

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.

Work on web accessibility therefore also improves the semantic signals that compatible browser-agent frameworks read: semantic HTML, a proper heading hierarchy, labeled forms, descriptive links, and ARIA where needed.

Since 94.8% of the top 1,000,000 websites show detectable WCAG failures, most sites have room to improve. A better accessibility tree helps users with disabilities and snapshot-dependent browser agents. It does not guarantee recommendations, citations, transactions, or overall agent readiness, but it removes avoidable semantic 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