Accessibility work is agent readiness work

If your team has spent time making your site work with screen readers and keyboards, you've already done a large share of the work to make it work for AI agents. The reason is simple: many browser agents read a page through the same structure that assistive technology uses.

How a browser agent sees a page

A person looks at a page and sees layout, color and images. A browser agent, the kind that opens your site in a real browser to search, fill in forms and add to cart, needs something it can reason about and act on. It has two main options.

• Screenshots. The agent looks at an image of the page and decides where to click. This works, but it's slow, and it struggles with small icons, overlapping elements and anything that looks clickable but isn't.
• The accessibility tree. Browsers already build a structured version of every page for assistive technology: each heading, link, button and form field, with its role (what kind of thing it is), its name (what it's called) and its state (checked, expanded, disabled). Many agents read this tree, often alongside screenshots, because it tells them exactly what can be clicked and what each thing is for.

The tooling used to build agents reflects this. Playwright's MCP server, a widely used way to give an AI model control of a browser, hands the model an accessibility snapshot of the page rather than pixels. In that snapshot, a button is a line like button "Add to cart". A button with no name is just button, and the agent has to guess.

<!-- What the agent can use -->
<button type="submit">Add to cart</button>
<button aria-label="Open cart"><svg aria-hidden="true">…</svg></button>

<!-- What it can't -->
<div class="btn" onclick="addToCart()"><svg>…</svg></div>

The last example has no role and no name. A screen reader user can't use it, and an agent reading the accessibility tree may not know it exists.

Where WCAG and agent readiness overlap

The Web Content Accessibility Guidelines (WCAG) 2.2 are the standard most accessibility programs work to. Several of their success criteria line up closely with AgentScore checks.

WCAG 2.2 success criterion	Related AgentScore check
4.1.2 Name, Role, Value	Buttons and links have names; Clickable things are real buttons and links
1.3.1 Info and Relationships, 3.3.2 Labels or Instructions	Form fields are labelled; Cart and checkout fields are labelled for agents
1.1.1 Non-text Content	Images have text descriptions
2.4.1 Bypass Blocks, 1.3.1 Info and Relationships	Page has main and navigation landmarks
2.4.2 Page Titled, 2.4.6 Headings and Labels	Clear page title, description, and headings
2.1.2 No Keyboard Trap, 2.4.11 Focus Not Obscured (Minimum)	Pop-ups and banners can be dismissed by agents

The match isn't exact. WCAG asks more of each criterion than our checks test for, and our checks look at things from an agent's point of view. But the direction is the same: give every control a role and a name, label every field, describe every meaningful image, and structure the page so it can be navigated without seeing it.

Our guide to buttons, links and forms agents can use covers the fixes in detail, and alt text for AI agents covers product images.

Common accessibility gaps that also stop agents

• Icon-only buttons with no label. The cart, search and menu icons in a header are the usual culprits. Add visible text or an aria-label.
• Placeholder text used as a label. It disappears when the field is filled in and isn't a reliable name. Use a real <label>.
• Clickable boxes. A div with a click handler looks like a button to a person and like plain text to the accessibility tree. Use <button> or <a href>.
• Menus that only open on hover. Neither keyboard users nor many agents can hover. Open them on click and focus too.
• Custom size and color pickers. If a swatch has no name and no selected state, an agent can't tell which size it chose. Native radio buttons or properly labelled custom controls fix this.
• Pop-ups without a labelled close button. See cookie banners and pop-ups that trap AI agents.

Where they differ

Accessibility work won't cover everything, and some of it doesn't matter to agents at all.

Agent readiness needs more than accessibility. A perfectly accessible site can still block AI assistants in robots.txt, challenge them with bot protection, or load its prices with JavaScript that many AI crawlers never run. Screen readers work inside a real browser, so they see JavaScript content; many agents don't. Structured data, sitemaps and llms.txt matter to agents and have little to do with accessibility. That's why AgentScore has Access and Readability categories as well as Navigability.

Some accessibility work matters less to agents. Color contrast, text resizing, captions and motion settings are essential for people and largely irrelevant to software. Don't use agent readiness as a reason to deprioritize them. They serve customers, and in many places they're a legal requirement.

Bad ARIA hurts both. The W3C's own guidance is that no ARIA is better than bad ARIA. An aria-label that says "button", a role="button" on something that can't be pressed, or aria-hidden="true" on a real control misleads screen readers and agents alike. Native HTML elements are almost always the better choice.

How to use this

1. Ask your accessibility lead for the latest audit. Unlabelled controls, missing form labels and keyboard traps in that report are agent readiness issues too. Fixing them pays twice.
2. Add an agent's view to your testing. Run AgentScore and compare its Navigability findings with your audit. Then send a Ghost Agent through checkout to see whether a real agent can finish.
3. Make it part of the definition of done. New components ship with names, labels and native elements. That's cheaper than fixing them later, for people and agents alike.

Accessibility and agent readiness come from the same idea: a website should work for visitors who don't see it the way its designers do. More and more of those visitors are software acting for a person.