AI agents are browsing the web on behalf of users right now. Chrome’s auto browse scrolls, clicks, and types autonomously for AI Pro and Ultra subscribers. ChatGPT’s Atlas navigates and helps with purchases. Perplexity’s Comet researches across tabs and fills forms.
These agents don’t see your website the way a human does. They can’t parse your CSS layout or appreciate your animations. They read structure, and the structure they depend on is the same one that makes sites accessible to humans.
If your site isn’t accessible, it’s increasingly invisible to the agents handling your customers’ transactions.
How AI Agents Actually Read Your Website
Different agents take different approaches, and the trend across the industry is worth understanding.
Some are vision-led. Anthropic’s Computer Use processes screenshots and counts pixels to position the cursor on a button or in a form field. This approach is computationally expensive and fragile when layouts shift.
Some lead with the accessibility tree. Microsoft’s Playwright MCP, the official MCP server for browser automation, provides accessibility snapshots rather than screenshots, giving AI models a structured semantic representation of the page. ChatGPT Atlas takes a similar tack. OpenAI’s Publishers and Developers FAQ states that “ChatGPT Atlas uses ARIA tags, the same labels and roles that support screen readers, to interpret page structure and interactive elements,” and explicitly directs publishers to follow WAI-ARIA best practices.
Most production agents fall somewhere in between, layering screenshot analysis with DOM and accessibility tree parsing. Google’s Project Mariner observes both visual elements and underlying page structure before planning actions. OpenAI’s Computer-Using Agent, which powers Atlas, follows a similar hybrid pattern.
The pattern across the industry is consistent. Even platforms that started with vision are incorporating accessibility data. The ones optimizing for reliability and speed lead with the accessibility tree.
Your site’s accessibility tree isn’t a compliance artifact anymore. It’s becoming the primary interface between your website and the agents that want to use it.
Why the Accessibility Tree Works So Well for Agents
Your page’s DOM might contain thousands of nodes. The accessibility tree strips that down to what’s actually interactive: buttons, links, form fields, headings, and landmarks. For AI models operating within a limited context window, that reduction matters. Instead of processing the full DOM, the agent gets a clean semantic map of the page.
Researchers at UC Berkeley and the University of Michigan recently published the A11y-CUA dataset at CHI 2026, the leading conference on human-computer interaction. They tested Claude Sonnet 4.5 on 60 everyday desktop and web tasks under three conditions: standard access, keyboard-only navigation (simulating screen reader workflows), and a 150% magnified viewport (simulating low-vision tools). They also collected over 40 hours of comparison data from 16 sighted, blind, and low-vision users completing the same tasks.
The agent results were stark:
Under standard conditions, the agent completed about 78% of tasks successfully.
With keyboard-only access, success dropped to 42%, and tasks took roughly twice as long.
With a magnified viewport, success fell to 28%, and tasks took more than three times longer.
These conditions aren’t artificial. Accessibility-tree agents identify and act on elements through the same semantic structure that keyboard navigation depends on. When that structure is missing or broken, keyboard users hit dead ends, and agents do too. Accessible interfaces give agents the information they need to act. Inaccessible interfaces force them to guess, retry, and eventually give up.
The Accessibility Practices That Matter Most
You already know most of this. That’s the point. The work AI agents need from your code is the same work the accessibility community has been asking for. But let’s get specific about what matters most in an agentic context.
Use semantic HTML. Really use it.
This is the foundation. Native HTML elements automatically generate meaningful entries in the accessibility tree. A The Agents also use landmark elements to understand page structure: An agent reading this page knows exactly where the navigation is, where the main content starts, and how the information is organized. A page built entirely with Every form input needs a Agents identify form fields by their accessible names. No label means the agent has to guess what the field is for. This is especially critical in multi-step forms where the agent needs to map user intent ("enter my email") to the correct field. For buttons, be specific: The W3C's first rule of ARIA, as it's commonly summarized, is "don't use it." The actual rule says to prefer native HTML elements when one exists with the semantics and behavior you need. That should tell you something about how often ARIA gets misused. Adding Where ARIA does help: dynamic content that updates without a page reload. Live search results, notification counts, status messages. And for custom components where no native equivalent exists: Without Browser-based agents like Atlas and Comet run on Chromium and execute JavaScript. But many AI crawlers and search indexers do not. If critical content is only available after client-side rendering, a growing segment of agent traffic will never see it. Server-side rendering or static generation means your content is in the HTML from the start. Every agent, regardless of its JavaScript capabilities, can read it. You don't need a new toolset for this. The tools the accessibility community has built over the past decade are exactly what you need. Every major browser exposes it. In Chrome DevTools, open the Elements panel and look for the Accessibility pane. You can also enable the full accessibility tree view in Chrome's experiments. This shows you exactly what an agent sees. Walk through a key user flow on your site, the one you'd most want an AI agent to complete. For each step, check the accessibility tree. Can you identify the next action from the tree alone, without looking at the visual page? If you can't, neither can an agent. A web accessibility scanner will catch the low-hanging issues fast: missing labels, empty buttons, heading hierarchy violations, and missing alt text. These won't catch everything, but they'll flag the structural problems that break agent navigation. AudioEye's free Web Accessibility Scanner tests any URL against WCAG criteria and returns a prioritized report of what's blocking access, for humans and agents alike. Run it against your highest-intent pages first: checkout, signup, search, account. Navigate your entire checkout or conversion flow using only your keyboard. Can you reach every interactive element? Is the focus order logical? Can you complete the full flow without a mouse? Keyboard navigation is how most accessibility-tree-based agents interact with the web. If a keyboard user can't complete a task, an agent probably can't either. Headings create the outline agents use to navigate content. Run a quick check: are your headings in a logical hierarchy (h1, then h2, then h3, without skipping levels)? Do they describe the content that follows? Chrome's auto browse launched in January 2026. ChatGPT Atlas, Perplexity Comet, and a growing list of AI browsers are already shipping. Every major platform is investing in agents that act on behalf of users. This isn't a future trend. It's current traffic. Here's what makes this moment different from every other "optimize for the new thing" push in web development: the work has already been done. Not by you, necessarily, but by the accessibility community that spent decades defining what good web structure looks like. They weren't building for AI agents. They were building for people. Building for people was always the right architecture. Semantic HTML wasn't a compliance checkbox. It was a blueprint for a web that any system, human or machine, could understand. Proper labeling wasn't busywork. It was the foundation of a web that could be navigated by anyone, through any interface. The web didn't get a second audience. It revealed that the audience accessibility advocates were always serving a bigger audience than anyone realized. Every label you add, every native button you choose, every heading hierarchy you respect compounds. It works for the screen reader user today, the AI agent tomorrow, and the next interface we haven't imagined yet. That's the rare gift of building things right. The principles have been in the HTML standard for years. The teams that built on them, and the platforms that maintain them at scale, have been quietly preparing the web for this moment all along. The future doesn't need to be retrofitted. It just needs to find you ready.
<button type="submit">Complete Purchasebutton>
<div class="btn btn-primary" onclick="handleSubmit()">Complete Purchasediv> communicates its role, name, and state to both assistive technologies and AI agents automatically. The <header>
<nav aria-label="Main navigation">
<ul>
<li><a href="/products">Productsa>li>
<li><a href="/pricing">Pricinga>li>
ul>
nav>
header>
<main>
<article>
<h1>Product Nameh1>
<section aria-labelledby="features-heading">
<h2 id="features-heading">Featuresh2>
section>
article>
main> tags gives agents nothing to work with.
Label everything interactive
. Every button needs descriptive text. Every icon-only control needs an accessible name.
<label for="email">Email addresslabel>
<input type="email" id="email" name="email" autocomplete="email">
<input type="email" placeholder="Enter your email">
<button type="submit">Add to Cartbutton>
<button type="submit">Submitbutton>
<button><svg class="icon-cart" />button>
<button aria-label="Add to cart"><svg class="icon-cart" aria-hidden="true" />button>Use ARIA correctly, which mostly means using less of it
role="button" to a provides. ARIA supplements situations where native HTML can't express the semantics you need. It doesn't replace the work of using the right element in the first place.
<div aria-live="polite" aria-atomic="true">
<p>3 results foundp>
div>
<button aria-expanded="false" aria-controls="details-panel">
Show Details
button>
<div id="details-panel" hidden>
div>aria-expanded, an agent doesn't know this button toggles content. It might click it, see nothing obvious change because the content appeared below the fold, and move on.Make content available without JavaScript when possible
<div class="product-price">
<span>$49.99span>
<span class="sale-badge">20% offspan>
div>
<div id="price-container">div>
<script>
fetch('/api/price').then(r => r.json()).then(data => {
document.getElementById('price-container').innerHTML =
``;
});
script>How to Audit Your Site for AI Agent Readiness
Inspect your accessibility tree
Run automated checks
Test with a keyboard
Check your headings
<h1>Running Shoesh1>
<h2>Men's Running Shoesh2>
<h3>Trail Runningh3>
<h3>Road Runningh3>
<h2>Women's Running Shoesh2>
<h1>Productsh1>
<h3>Categoryh3>
<h4>Itemsh4>Why This Matters Now, Not Later
