A striking irony has taken shape in 2026. The AI agents now browsing, comparing, and buying across the web read pages through the accessibility tree, the same stripped-down structural representation of a page that has powered screen readers for two decades. The structured, concise, well-labeled content those agents need is almost exactly the accommodation blind and low-vision users have asked developers for since the early days of the web, usually in vain. The difference now is the audience. When the reader is a paying bot rather than a disabled person, businesses are suddenly motivated to provide it.
What the accessibility tree actually is
When a browser renders a page, it builds more than the visual layout. It also constructs an accessibility tree: a parallel model of the page expressed as roles, names, states, and relationships. A button is a button with an accessible name. A form field has a label. A heading marks the start of a section. Screen readers have consumed this tree for twenty years to narrate a page to someone who cannot see it. The tree is only as good as the markup underneath it, which is why semantic HTML and correct ARIA matter so much.
AI agents have arrived at the same door. Rather than interpret a wall of pixels, an agent that needs to complete a task reads the accessibility tree to understand what is on the page and how to act on it. As reporting from Search Engine Journal put it, the accessibility tree is how AI agents read your site, and where the markup is broken or missing, agents stumble in the same places screen reader users always have.
Bots are now the majority of the audience
The commercial pull is not hypothetical. Automated bots made up 57.2 percent of HTTP requests to HTML content in May and June of 2026, against 42.8 percent from humans, as documented in Tech Policy Press. Shopping bots, research assistants, and task agents are, for the first time, a larger share of the traffic reading web content than people are. For a business, that reframes accessible structure from a compliance chore into a way to be found, understood, and transacted with.
So teams are investing. The industry has a fresh vocabulary for it, and the phrases give the game away.
- "AI readiness" and "agent readiness": shorthand for making a site legible to autonomous software.
- The specific work: semantic HTML, correct ARIA, clear and unique labels, and structured data.
- The specific motive: revenue. Agents that can navigate a checkout convert; agents that cannot move on to a competitor.
That list is, almost line for line, the accessibility backlog. As The Drum noted in its roundup of 2026 accessibility trends, agentic AI and the maturing regulatory landscape are converging on the same technical requirements. The work that makes a site scrapable and usable by an agent is the work that makes it usable by assistive technology.
The uncomfortable part
The uncomfortable part is the sequencing. For roughly twenty years, disabled users asked for exactly this: give me headings I can navigate, buttons that announce themselves, form fields with labels, a page structure that makes sense without sight. The request was framed as a civil-rights obligation, and for two decades it was treated as an afterthought, a line item deferred until a lawsuit made it urgent. Now the same accommodation is being built at speed, not because a person needs it, but because a bot with a shopping cart does.
The accommodation blind users spent twenty years requesting is being delivered the moment a paying machine asks for the same thing.
It would be easy to be cynical about this, and some cynicism is earned. But the more useful response is to notice that the incentives have finally, accidentally, aligned. The question is what teams do with that alignment.
The risk of optimizing for agents only
The alignment is real, but it is not guaranteed. A team that treats agent readiness and human accessibility as two separate goals can easily make choices that serve one and betray the other. Hidden text stuffed into a page to feed a crawler does nothing for a screen reader user and can actively mislead one. Agent-only endpoints or parallel machine-readable feeds can let a business claim it is "AI ready" while the human-facing site stays as broken as ever. The moment accessibility is reframed as bot plumbing, it can drift away from the people it was meant to serve.
This is why standards still matter more than trends. WCAG success criteria such as Info and Relationships (1.3.1) and Name, Role, Value (4.1.2) describe a page structure that is correct for a human using assistive technology. Build to that standard and agents come along for free. Build to an agent spec alone and you have no guarantee a person can use what you shipped.
What this means: do it for people first
The constructive path is to keep the order of priorities straight. Do this work for people first, because it is a civil-rights obligation and, under the ADA and comparable laws, it is the law. Let the AI-agent benefits be the bonus, not the justification. That ordering is not just principled, it is practical: an approach anchored in real human accessibility produces markup that any agent can read, while an approach anchored in agent optimization produces markup that may leave humans behind.
- Anchor the work in WCAG conformance and a real human user need, not an "agent readiness" checklist.
- Test the way a person would experience the page. Screen reader testing catches the same broken structure that trips up agents, and it keeps a human in the loop.
- Refuse the shortcut of hidden text or agent-only endpoints. If a fix does not help a screen reader user, it is not accessibility.
The web is being rebuilt to be legible to machines, and for once that project overlaps almost perfectly with a promise the industry made to disabled users long ago and rarely kept. If you want to understand the shared vocabulary underneath all of this, our accessibility glossary is a good starting point. Build for people, and the agents will read it fine. Build only for the agents, and you will have missed the point entirely.