Back to Blog

Best Practices

How AI agents and AI search read your website

AI agents and assistive technology read your site the same way — through the accessibility tree. If your buttons are div soup, both a screen reader and an AI shopping agent are blind to them. Here is what that means for accessibility and visibility.

30 June 2026

11 min read

Ravid, Webply

For thirty years we built websites for two audiences: people who could see them, and people who used assistive technology to perceive them. A third audience has shown up, and it's growing fast — software agents. AI assistants that book the flight, compare the prices, fill the form, and complete the checkout on a human's behalf.

Here's the part nobody expected: that third audience reads your site the exact same way a blind user does. Which means the accessibility work you've been framing as a compliance chore is turning into the thing that decides whether an AI agent can use your business at all.

The accessibility tree: the map you can't see

When a browser loads your page, it builds two structures. There's the DOM — every element, style, and wrapper div, thousands of nodes. And there's the accessibility tree — a stripped-down version the browser exposes through an API, keeping only what matters: the headings, links, buttons, form fields, landmarks, and images, each tagged with its role (what it is), name (what it's called), and state (open, checked, disabled).

A page with several thousand DOM nodes might collapse to a couple of hundred meaningful nodes in the accessibility tree. That tree is what a screen reader announces to a blind user. It is, in the words of MDN's documentation, "a tree of accessible objects that represents the structure of the user interface."

And it turns out it's a near-perfect input for an AI agent too. As the W3C and browser vendors describe it, the accessibility tree is the page's semantic summary — it throws away the CSS noise and exposes the functional intent of every control. An agent reading it learns "this is a button named Add to cart, currently enabled" without having to guess from pixels.

How agents actually perceive a page

Production AI agents use a hybrid of three approaches, and understanding them tells you exactly what to fix:

• Vision — the agent takes a screenshot and interprets it like a human would. Powerful, but slow, expensive, and easily fooled by ambiguous visuals.
• DOM parsing — the agent reads the raw HTML. Complete, but noisy: thousands of nested wrappers with no signal about what's actually interactive.
• Accessibility-tree parsing — the agent reads the same semantic map assistive tech uses. Compact, high-signal, and unambiguous about roles and states. This is increasingly the preferred method.

The trend matters because the third method — the accessibility-tree method — is the one that scales. It's cheaper than vision and cleaner than raw DOM. So the better your accessibility tree, the more reliably agents can drive your site. Poor accessibility doesn't just exclude disabled humans now; it degrades you for the fastest-growing category of web traffic.

How fast-growing? For the week of 30 May–5 June 2026, Cloudflare Radar measured 57.2% of HTTP requests to HTML content coming from automated bots, versus 42.8% from humans. Not all of those are shopping agents — but the direction is unmistakable: more than half of what hits your pages is already a machine.

Google said the quiet part out loud

In April 2026, Google published a web.dev guide titled "Build agent-friendly websites." It lays out how agents interpret a page and what developers should do about it. Read the checklist and something jumps out — it's an accessibility audit wearing a different hat:

This is the headline for any team weighing accessibility against "more strategic" priorities: the agent-friendly web and the accessible web are the same web. Google is now telling you to do — for commercial, AI-readiness reasons — exactly what the EAA tells you to do for legal ones.

What to fix (and who else it helps)

The good news is you don't need a separate "AI optimisation" project. The fixes are the accessibility fundamentals, and every one of them pays into three buckets at once — disabled users, AI agents, and search crawlers.

• Use real interactive elements. A <button> for actions, an <a href> for navigation. A <div onclick> is invisible to the accessibility tree — and therefore to agents.
• Give every control an accessible name. Icon-only buttons (cart, search, hamburger, close) need a label. "Button, unnamed" tells a screen reader and an agent nothing.
• Link labels to inputs. A real <label for> tells both a screen reader and an agent what a field is for — no guessing from placeholder text that vanishes on focus.
• Announce state changes. When something is added, removed, errored, or loading, expose it in the markup (ARIA live regions, proper roles) — don't rely on a purely visual flash that only a sighted human catches.
• Keep structure and layout stable. Ordered headings, landmarks, and no surprise layout shifts. Agents (like humans) get lost when the page reflows under them.

The strategic reframe

For a decade, the business pitch for accessibility was some mix of "it's the right thing to do" and "you might get sued." Both true. Neither moves a sceptical executive quickly.

This is a third argument, and it's the one that lands in 2026: accessibility is the on-ramp to the agentic web. The same hidden map that lets a blind person buy from you lets an AI agent buy from you. As more purchasing, research, and comparison flows through agents, the sites that are illegible to machines quietly fall out of consideration — not with a lawsuit, but with a silent failure to be found, parsed, or transacted with.

The companies that invested in real accessibility didn't just reduce legal risk. They accidentally built the most machine-readable version of their business — and that's about to matter commercially in a way nobody framed it as five years ago.

Related reading

• Does web accessibility actually help SEO? What the data says
• The 10 most common WCAG violations — and how to fix them
• WCAG, EN 301 549 and the EAA — how the standards fit together