AI Agents Are Reshaping How Websites Need to Be Built
Chrome's auto browse scrolls and clicks on behalf of users. ChatGPT's Atlas navigates websites and completes purchases. Perplexity's Comet researches across tabs and fills forms. These agents are live now, handling real transactions for millions of people.
They don't see your website the way humans do. They can't parse your CSS layout or appreciate your animations. Instead, they read your accessibility tree-the semantic structure underneath your HTML. If that structure is missing or broken, your site becomes invisible to the systems managing your customers' interactions.
This is no longer a compliance issue. It's a business-critical development priority.
How AI Agents Actually Read Your Pages
Different platforms take different approaches, but the industry trend is clear. Some agents rely on vision: Anthropic's Computer Use processes screenshots and counts pixels to position cursors. This approach is computationally expensive and fragile when layouts shift.
Others lead with the accessibility tree. Microsoft's Playwright MCP provides accessibility snapshots rather than screenshots, giving AI models a structured semantic representation of the page. ChatGPT Atlas works similarly. OpenAI's documentation states that Atlas uses ARIA tags-the same labels and roles that support screen readers-to interpret page structure and interactive elements.
Most production agents use a hybrid approach. Google's Project Mariner observes both visual elements and underlying page structure. OpenAI's Computer-Using Agent, which powers Atlas, follows the same pattern. 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 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.
Researchers at UC Berkeley and the University of Michigan tested Claude Sonnet 4.5 on 60 everyday tasks under three conditions: standard access, keyboard-only navigation, and a magnified viewport. They compared results against 16 sighted, blind, and low-vision users completing the same tasks.
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, keyboard users hit dead ends and agents do too.
The Practices That Matter Most
Use semantic HTML. Really use it.
Native HTML elements automatically generate meaningful entries in the accessibility tree. A <button> communicates its role, name, and state to both assistive technologies and agents automatically. A <div class="btn"> communicates none of that without extra work.
Agents also use landmark elements to understand page structure. A page with <header>, <nav>, <main>, and <article> tags tells agents exactly where navigation is, where main content starts, and how information is organized. A page built entirely with <div> and <span> tags gives agents nothing to work with.
Label everything interactive.
Every form input needs a <label>. Every button needs descriptive text. Every icon-only control needs an accessible name. 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 to the correct field.
For buttons, be specific. "Add to Cart" is better than "Submit." Icon-only buttons need an aria-label attribute.
Use ARIA correctly, which mostly means using less of it.
The W3C's first rule of ARIA is "don't use it." The actual rule says to prefer native HTML elements when one exists with the semantics you need. Adding role="button" to a <div> doesn't give it keyboard focus, a click handler on Enter or Space, or any of the built-in behaviors a real <button> provides.
ARIA helps in two situations: dynamic content that updates without a page reload (live search results, notification counts, status messages) and custom components where no native equivalent exists. Use it to supplement, not replace, proper HTML structure.
Make content available without JavaScript when possible.
Browser-based agents like Atlas and Comet execute JavaScript. 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.
How to Audit Your Site for Agent Readiness
You don't need new tools. The tools the accessibility community built over the past decade are exactly what you need.
Inspect your accessibility tree. Every major browser exposes it. In Chrome DevTools, open the Elements panel and look for the Accessibility pane. Walk through a key user flow on your site-the one you'd most want an 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.
Run automated checks. A web accessibility scanner will catch 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.
Test with a keyboard. 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.
Check your headings. Headings create the outline agents use to navigate content. Are your headings in a logical hierarchy (h1, then h2, then h3, without skipping levels)? Do they describe the content that follows?
Why This Matters Now
Chrome's auto browse launched in January 2026. ChatGPT Atlas, Perplexity Comet, and a growing list of AI browsers are already shipping. 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: the work has already been done. The accessibility community 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 was bigger 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.
If you're building web applications, start with AI for Web Developers to understand how these systems interact with your code. For deeper technical skills, explore AI Coding Courses that cover semantic HTML, ARIA implementation, and modern web standards.
The principles have been in the HTML standard for years. The future doesn't need to be retrofitted. It just needs to find you ready.
Your membership also unlocks:
