The semantic structure screen readers have used for decades now also decide whether ChatGPT, Claude, Gemini, Grok, and Perplexity can read your page at all.
In 2016 I had a series of calls with the federal government’s top accessibility expert as the leader of a design team, and I learned more in those conversations than in years of reading specifications. I had already been building accessible web applications since 2006, chasing Level AAA when most teams would not commit to AA. I learned so much, and it’s always been top of mind.
The lede even back then: accessibility matters, and we should pay attention to it.
For a long time that work served a small, often-overlooked audience you defended on principle alone.
That argument just changed just got larger.
Your website has a new kind of visitor, and it does not look at your page the way you do. It reads a stripped-down model of the page called the accessibility tree — the same structure browsers have built for screen readers for two decades. It doesn’t know what a color is; it looks for well-labeled structure.
If you don’t have it, it can’t find you. And most sites don’t have it.
The numbers: In early June 2026, Cloudflare reported that automated traffic had passed human traffic on the web for the first time, roughly 57 percent of page requests against 43 percent.
A fast-growing share of web traffic is agents acting for people.
The audience that reads through structure of your pages to understand context is no longer a rounding error, it is most of your traffic. Welcome to inclusive design. The questions narrow: which agents read what, when accessibility becomes load-bearing, and the small set of categories worth fixing first.
I’ll be covering all of the major agents on how they read a page in a later series of articles because it’s fascinating, but this is a good place to start.
How the Major Vendors Read a Page
There are three ways an agent can take in a page: it can look at a screenshot with a vision model, read the raw HTML of the document, or read the accessibility tree the browser builds from that HTML.
Each has a cost.
A screenshot is expensive in tokens and easy to misread when layouts are dense. Raw HTML is noisy, thousands of tokens of wrappers and scripts around the few elements that matter, frankly because of poor engineering practices and human slop code.
The accessibility tree is the cheap, clean option: a short list of the interactive elements, their roles, their names, and their states. Google’s own guidance for developers is that capable agents combine all three, leaning on the structured channels and using the picture to confirm layout. That’s pricey, and also means 3 different results.
The vendors split on where they start
- Anthropic’s Computer Use is vision-first: Claude looks at screenshots and counts pixels to place the cursor, which is flexible but fragile when the screen shifts. Its browser extension, Claude in Chrome, leans the other way — its read_page tool takes the accessibility tree first, with a get_page_text tool for article-style pages and screenshots as the fallback.
- Microsoft went the other way, at least for developers. Its Playwright MCP, the official server for letting a model drive a browser, works from structured accessibility snapshots and skips vision entirely, on the stated premise that the structured view beats a screenshot. Its consumer surface is the opposite: in Copilot Mode in Edge, Copilot Actions read and act inside your signed-in session, leaning on what is on screen.
- Google’s Gemini agents sit in the hybrid middle. It blends the structured channels with a visual pass to confirm what the layout is doing rather than committing to one or the other. For users that shows up as Gemini in Chrome and its Auto Browse mode, with Project Mariner as the research agent behind it.
- The most telling case is OpenAI. Its Computer-Using Agent, which drives both Operator and the Atlas browser, started from screenshots. OpenAI’s own publisher guidance now tells site owners that Atlas uses ARIA tags, the same labels and roles that support screen readers, to interpret page structure, and points them to standard accessibility practices. Even the company whose agent leads with pixels is telling you to fix your accessibility tree.
When Accessibility Becomes Foundational
Accessibility does not matter equally on every page, and it is worth being precise about where it does.
For a page that is mostly prose, an agent can usually cope; the words are the content, and even a messy structure leaves them readable. The stakes rise the moment the agent has to act — to find the right button, fill the correct field, choose among options, and move through a flow without losing its place.
Transactional, multi-step, and dynamic interfaces are where a broken structure stops being an inconvenience and starts being a brick wall.
If a keyboard user cannot finish the task, the agent usually cannot either.
The evidence is getting concrete. In the A11y-CUA study presented at CHI 2026, researchers at UC Berkeley and the University of Michigan ran Claude Sonnet 4.5 through 60 everyday web and desktop tasks under different conditions.
- With normal access the agent finished about 78 percent of them.
- Constrained to keyboard-only navigation — the path an accessibility-tree agent depends on — success fell to 42 percent, and the work took roughly twice as long.
- Under a magnified viewport it dropped to 28 percent.
The same structural gaps that strand a screen-reader user strand the agent. If a keyboard user cannot finish the task, the agent usually cannot either. Accessible structure is not a separate track from agent-readiness; it is the track.
Legibility Is Not Endorsement
Building a page an agent can read is not the same as endorsing every agent that reads it. Anil Dash has argued that some of these products are openly hostile to the open web, substituting synthesized summaries for the pages and links underneath.
Legibility and approval are different things.
He is right that legibility and approval are different things. You can make your page structurally honest and still decide a given browser is a bad deal for the web, and hold the two judgments apart. The discipline stands on its own terms: it serves the people using assistive technology no matter what you make of any agent.
The Nielsen Norman Group makes the parallel case from the design side, treating agents as a class of user you now serve whether you meant to or not — which is a reason to build for them, not a verdict on them.
There is a sharper version of the cost, and it cuts against the grain of this whole piece. A page that is accessible and semantically correct is the easiest kind of page for an AI assistant to read, summarize, and answer from — which makes it the easiest kind to lift without sending anyone your way.
Do the structural work well and the assistant may cite you, paraphrase you, and keep the user inside its own answer.
It’s literally reverse SEO — honor the standards and pay the cost. Welcome to the world of AI.
The same legibility that wins the agent can cost you the click, and the ranking that used to come with it. That is a real tradeoff, not a reason to ship a broken page, but go in with your eyes open.
Where To Start
Category One: Semantic Structure and Landmarks
This is the foundation, and the cheapest win. Native HTML elements announce themselves in the accessibility tree without any extra work. A <button> is a button the agent can find and trust.
A <div> wired up with a click handler is an unnamed, role-less box the agent has to guess about, and it guesses wrong often enough to matter. The web.dev guidance is unglamorous on purpose: use the element that means what you intend, and most of the structure takes care of itself.
Two things sit on top of that foundation. Headings are the outline an agent reads to understand what a page contains and how its parts relate; a logical order, h1 to h2 to h3 without skipped levels, gives the agent a map instead of a pile.
Landmarks — navigation, main, header, footer — tell it which region it is standing in.
None of this is new advice. It is the same structure the field has taught for years, now with a second reader who takes it literally.
Category Two: Names, Roles, and States
Every control an agent might use needs a name in the tree, a role that says what it is, and — when it changes — a state that says what it is doing now. This is where most real pages fail. Icon-only buttons with no label, links that all read “read more,” custom dropdown menusand modals built from generic markup: each one lands in the accessibility tree as a blank or a question mark.
The agent can see that something is there and cannot tell what it does.
ARIA exists to fill the gaps native HTML cannot express — to give a custom widget the role and state it would otherwise lack. But it comes with a sharp rule the vendors tend to skip past.
The First Rule of ARIA is not to use ARIA: if a native element already carries the meaning, use it, because a wrong or empty ARIA attribute is worse than none.
It does not leave the tree blank; it fills the tree with confident, incorrect information, and the agent has no way to know it is being misled. OpenAI’s guidance tells publishers to reach for ARIA. Accessibility practitioners have pushed back that the durable fix is correct markup, not bolt-on attributes — and the data is on their side.
Here is the part that should bother you. In 2026, web accessibility got worse for the first time in six years. WebAIM’s annual scan of the top million home pages found detectable WCAG failures on 95.9 percent of them, up from 94.8 percent, with the average page carrying about 56 errors across 1,437 elements — a 22.5 percent jump in page complexity in a single year. ARIA usage climbed 27 percent, and the pages reaching hardest for it carried the most errors.
WebAIM names a likely culprit: AI-assisted coding. The same wave of agents now reading your page is helping generate the broken structure that makes it unreadable.
We’ll talk about that harness needed in a later article.
Category Three: Text Alternatives and Labels
This category is about the content that is real on the page but invisible in the structure unless you make it explicit. Images are the obvious case: without alternative text, an agent cannot tell a product photo from a logo from a chart, and a linked image with no alt text becomes a link to nowhere. WebAIM still finds missing alternative text among the most common failures on the web, year after year.
An agent cannot fill a field it cannot name.
Form fields are the same problem in a different place. An agent cannot fill a field it cannot name, so a label tied to its input is the difference between a completed checkout and an abandoned one.
The fix is dull and well understood: real alternative text on meaningful images, an empty alt on decorative ones, and a programmatic label on every input.
Category Four: Feedback and Stable Layout
The last category is about what happens after the agent acts. State has to be announced, not just shown. If a confirmation appears only as a visual change, the agent acts as if nothing happened.
If a confirmation appears only as a visual change, the agent acts as if nothing happened.
A result, an error, or a status update that never reaches the tree leaves the agent guessing; live regions and managed focus are how you tell it the page moved.
And layout has to hold still.
Agents that fall back to a screenshot lose their footing when the same control sits in a different place on every page, so consistency stops being a matter of polish and becomes a matter of whether the agent can find the thing at all.
The Work Is Already Specified and Has Been For Years
Here is the reassuring part, rare in a piece about new technology. You are not being asked to optimize for some proprietary new format. The thing agents need from your page is the thing the accessibility community has asked for all along: semantic markup, named controls, real text alternatives, honest state, stable layout.
That work used to pay once, for the people using assistive technology. Now it pays twice, because the same structure is what the machines read.
So treat it as triage, not a rebuild. Do not try to agent-proof every page. Find the flows where an agent has to act — the checkout, the booking, the account change — and make those legible first.
Open your browser’s developer tools, look at the accessibility tree for that flow, and ask whether you could finish the task from the tree alone. Then walk it with the keyboard only. Where you hit a wall, so does the agent.
The audience that reads through structure was easy to ignore when it was small. It is not small anymore. The web you can see is increasingly the smaller half of the room, and the other half is reading the tree you built — or the one you didn’t.
Here’s What to Consider
Before you change anything, weigh these:
- Whether an agent would act on the page, not just read it. Static prose is low-stakes; the checkout, the booking, and the account change are where structure turns load-bearing.
- Whether you could finish the key flow from the accessibility tree alone. Open your developer tools, look, and then walk the same flow with the keyboard only. Where you stall, the agent stalls.
- Whether every control has a name, a role, and a state. Icon-only buttons and links that all read “read more” are the blanks that strand an agent.
- Whether you are reaching for ARIA to patch markup that should be native. A wrong or empty attribute is worse than none, because it fills the tree with confident, incorrect information.
- Whether images, fields, and feedback are spelled out. Alt text, tied labels, and announced state are what keep them from being invisible in the structure.
- Whether the layout holds still across similar pages. An agent that falls back to a screenshot loses its place when the same control moves.
- Whether legibility means endorsement. It does not — you can build an honest page and still judge a given agent a bad deal for the web.
Secret agent bot: accessibility matters for the agents even if you can’t see them was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.