Agent Ready Website: What AI Browser Agents Need to Read

A browser agent is software that opens a web page and uses it on someone's behalf: it reads the page, picks a link, fills in a form, presses the button. If your site's buttons have no names, its form fields have no labels and its menus are built from bare div elements, the agent gets stuck in the same places a screen reader user does. That is the whole idea behind an agent ready website, and it is good news, because the fix is work you can already measure against WCAG 2.2.

This guide explains what agents read, the five failures that stop them, the markup that fixes each one, and how to check your own site. You can run a free accessibility scan on any page while you read, and our AI agent readiness page maps each need to the check that finds it.

How a browser agent reads your page

Agents differ, and they change often, but they read a page in some mix of three ways:

• The HTML the browser has rendered: element types, attributes and text.
• The accessibility tree. The browser builds this from the HTML for assistive technology. Each node has a role (button, link, textbox, heading), an accessible name and a state (checked, expanded, disabled). It is what a screen reader reads aloud.
• Screenshots, read by a vision model, with clicks sent as screen coordinates.

Some of this is documented by the people who build them. Microsoft's Playwright MCP server, which lets an AI model drive a browser, says it "uses Playwright's accessibility tree, not pixel-based input". OpenAI's publishers and developers FAQ says its Atlas browser uses ARIA, the same roles and labels screen readers rely on, to understand page structure and controls, and advises site owners to follow WAI-ARIA best practices for buttons, menus and forms. Anthropic's computer use tool works the other way, from screenshots, with click coordinates "in screenshot pixels".

So an agent that reads the tree needs the structure to be in the markup, and an agent that reads pixels needs what is on screen to be legible and big enough to hit. Both are WCAG topics.

Is your website AI ready? The five failures that stop agents

These are the problems that leave an agent with nothing to choose by. Each is also a WCAG failure that hurts people using assistive technology, which is why fixing them is not a bet on any one AI product.

1. Icon buttons with no accessible name

A button that shows only an icon has a role but no name. In the accessibility tree it reads as "button" and nothing else, so a cart button, a search button and a menu button look identical. This fails 4.1.2 Name, Role, Value (Level A).

<!-- Broken: the tree says "button" and nothing more -->
<button class="icon-cart">
  <svg viewBox="0 0 24 24">...</svg>
</button>

<!-- Fixed: the tree says "button, View cart" -->
<button class="icon-cart" aria-label="View cart">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">...</svg>
</button>

Our ARIA checker flags buttons and links with no name. The same rule applies to linked logos and image links, where the name comes from the alt text (see how to write alt text).

2. Custom controls with no role

A div with a click handler looks like a button and acts like one for a mouse. To the accessibility tree it is a generic container with some text in it, so an agent that looks for interactive elements may not find it, and a keyboard cannot reach it. That fails 4.1.2 and 2.1.1 Keyboard.

<!-- Broken: a generic element with a click handler -->
<div class="btn" onclick="addToCart()">Add to cart</div>

<!-- Fixed: a real button, focusable and announced as one -->
<button type="button" onclick="addToCart()">Add to cart</button>

The same goes for custom dropdowns, tabs and toggles. If you build them yourself, they need the right role and state, as in aria-expanded="true" on a menu button, so the tree says what they are and whether they are open. Our guide to ARIA attributes covers the patterns, and the keyboard accessibility checker flags click handlers with no keyboard access.

3. Form fields with no programmatic label

A placeholder is not a label. It disappears when someone types, and a field labelled only by nearby text has no name in the accessibility tree. An agent filling a checkout form then has to guess which box is the postcode. This fails 1.3.1 Info and Relationships and 4.1.2.

<!-- Broken: no label, only a placeholder -->
<input type="text" name="zip" placeholder="ZIP">

<!-- Fixed: a label tied to the field, and the purpose stated -->
<label for="zip">ZIP or postal code</label>
<input type="text" id="zip" name="zip" autocomplete="postal-code">

The autocomplete value is a bonus: it states the field's purpose in a fixed vocabulary that browsers and password managers already understand (1.3.5 Identify Input Purpose). The form label checker finds unlabelled fields, and our accessible forms guide covers errors and grouping.

4. Names that do not match what is on screen

An agent working from a screenshot sees the word on the button. An agent working from the tree sees the accessible name. When they disagree, the two kinds of agent are looking at different pages, and so are people who use voice control. WCAG has a criterion for exactly this, 2.5.3 Label in Name (Level A): the accessible name has to contain the visible text.

<!-- Broken: shows "Buy now", the tree says "Proceed" -->
<button aria-label="Proceed">Buy now</button>

<!-- Fixed: let the visible text be the name -->
<button>Buy now</button>

Most of the time the fix is to delete an aria-label that was never needed. Visible text already names a button.

5. Links and structure that all look the same

Ten links called "Read more" are ten identical entries in the accessibility tree. A page with no headings and no main landmark gives an agent no way to skip the navigation and find the content. Link text that says where it goes (2.4.4 Link Purpose) and a real heading outline with landmarks (1.3.1) fix both, and the link text checker finds the vague ones.

What helps agents that read screenshots

For a vision model, the page is a picture. What helps a person with low vision tends to help here too: text with enough contrast to read (contrast requirements), and click targets large enough and far enough apart to hit by coordinates (WCAG 2.5.8 target size). Text set as real HTML text, rather than baked into an image, is readable either way.

Some things that block agents are outside WCAG altogether: bot checks, sign-in walls, rate limits, cookie banners that cover the page. Whether you want agents to get past those is a business decision, not an accessibility one, and an audit will not answer it.

How to check if your website is AI agent ready

You can see your site the way a tree-reading agent sees it in a few minutes, with tools you already have.

Look at the accessibility tree in Chrome

Open DevTools, go to the Elements panel, open the Accessibility tab and turn on Show accessibility tree. The DOM is replaced by the full page tree. Walk through your main task, such as add to cart or book a call, and look at every control on the way. Each one should have a role you would expect and a name you could act on. "button" with no name, "generic" where a button should be, and "textbox" with no name are the three things to look for.

Dump the tree with Playwright

If you write tests, Playwright's ARIA snapshots give you "a YAML representation of the accessibility tree" of a page or part of it, one element per line with its role and name:

// Prints the checkout form as an agent reading the tree sees it
const tree = await page.locator('form#checkout').ariaSnapshot();
console.log(tree);
// - textbox "Email"
// - textbox "ZIP or postal code"
// - button "Place order"

Store the snapshot and compare it in CI, and a later release that drops a label or a name fails the build instead of reaching users.

Do the keyboard pass

Tab through the same task without a mouse. Anything you cannot reach or operate with the keyboard usually has a role problem underneath, and that is what trips a tree-reading agent too. Our keyboard testing guide has the full procedure, and if the task opens a dialog, the accessible modal dialog guide covers what it has to do.

Scan for the patterns

Our free scan runs automated WCAG 2.2 AA checks in a real browser and finds the unnamed buttons, unlabelled fields, clickable divs and vague links across a page in a couple of minutes. It does not give an agent readiness score, and it cannot tell you whether a particular agent can finish a particular task. Automated checks find many real problems but cannot confirm that a page conforms to WCAG, and nobody can promise that fixing them changes how any AI product treats your site, since they do not publish that.

What to tell a client or a manager

Keep it to three sentences. AI agents that browse for people read the same labels and structure screen readers use, and at least one of the companies building them, OpenAI, tells site owners to follow WAI-ARIA best practices for that reason. The problems that stop agents are WCAG failures we can find and fix, so the work pays off for disabled visitors whatever happens with agents. We will not promise more traffic from AI, because nobody can.

Checklist

• Every button and link has a name in the accessibility tree, including icon buttons and image links.
• Every interactive element is a real button, a, input or select, or has the right role and state.
• Every form field has a label, and personal data fields have an autocomplete value.
• Accessible names contain the visible text.
• Links say where they go, and the page has headings and a main landmark.
• Text has enough contrast and targets are at least 24 by 24 CSS pixels or spaced to match.
• You have walked your main task in the accessibility tree and with the keyboard.
• You have run a free scan on the pages that matter and fixed what it found.