Browser agents read a web page through the same structure a screen reader uses. When that structure is missing, the agent has the same problem a blind user has, and it fails in the same places. I work on accessibility for a living, and most of what I fix for people turns out to be what an agent needs too. This page sets out the evidence, what I have built for agents on a11y.world, and how I would test an agent against it.

Agents read the accessibility tree

Two common tools for letting an agent drive a browser say so directly. Microsoft's Playwright MCP server describes itself as letting models "interact with web pages through structured accessibility snapshots, bypassing the need for screenshots," and it uses "Playwright's accessibility tree, not pixel-based input." OpenAI's publisher guidance for ChatGPT Atlas says that Atlas reads ARIA tags, the labels and roles that screen readers use, to work out page structure and what each control does. The same page tells site owners that making a site more accessible helps the Atlas agent understand it.

The accessibility tree is what the browser builds from the page for assistive technology. Each control in it has a role and an accessible name, and many also have a state such as checked or expanded. A button with an icon and no text has the role "button" and an empty name. A screen reader announces "button." An agent reading a snapshot sees the same empty node and has to guess what it does.

Most of the web is not ready

The WebAIM Million for 2026 tested the home pages of the top one million sites with automated checks. It found detectable WCAG 2 failures on 95.9 percent of them, up from 94.8 percent in 2025, and an average of 56.1 errors per page. Automated checks find only part of what is wrong, so real conformance is lower.

Several of the most common failures are the ones that leave an agent with nothing to read:

• Missing form input labels, on 51 percent of home pages. The agent sees a text field with no name and has to infer what to type into it.
• Empty links, on 46.3 percent. The agent sees a link with no name and cannot tell where it goes.
• Empty buttons, on 30.6 percent. The agent sees a control with no name and cannot tell what it does.
• Missing alternative text, on 53.1 percent. An agent working from the tree gets no description of the image.

WebAIM also reports that the growth in ARIA code on home pages correlates with more detected errors. Adding ARIA does not fix a page by itself. The W3C's guidance on using ARIA is to use a native HTML element when one exists and to add ARIA only when it does not. That advice holds for agents as well. A real <button> with visible text gives the agent a name, a role, and keyboard behavior with no extra work.

Guidance written for agents to follow

Most accessibility guidance assumes a person with time to interpret it. Agents now write HTML and describe images, so I wrote a version they can act on directly. The For Agents section of a11y.world has these parts:

• rules.json has 35 rules with stable ids such as AW-ALT-001. Each rule has a severity, a test method, a fix, and a link to the human note. Version 0.2.0 was published on October 2, 2026, under CC0.
• agents.md has the same rules as a prose checklist, plus decision procedures for alt text and focus states.
• A checklist for code-generating assistants lists 18 checks to run before returning HTML or CSS. Each check ties to a rule id and a corpus page.

I kept each rule short enough for an agent to apply. The alt text rule, for example, tells the agent to ask what the image does on this page before describing what it shows, and to leave the alt empty if the image does nothing. A rule like "make images accessible" gives an agent nothing to act on.

A test corpus with planted failures

Guidance is only useful if you can check whether an agent follows it. The test corpus is 30 small HTML pages. Twenty nine have planted, labeled violations, 53 findings in all. Page 14 is clean on purpose, so any finding there is a false positive. The scorer, score.mjs, matches each reported finding by rule id and element. It prints precision, recall, the misses, and a breakdown by rule.

I built it this way because it is how I evaluate models in general. On Evaluation I describe the same approach for local models. The cases come from real material, each case has explicit pass criteria, and the score does not depend on a second model's judgment. A planted failure with a known answer tells you more than a page that "looks fine" to a reviewer.

No agent has been scored against this corpus yet. Only the scorer's self-tests exist.

Asking agents who they are

This site has its own page for agents. /agents asks every visiting agent seven questions. Two of them ask who the agent is and whom it represents. Any answer can be "undisclosed." In browsers that support WebMCP, the page registers four tools on document.modelContext, so a browser agent can read and answer the survey without a form. Agents that only speak HTTP get a challenge token that lasts 15 minutes and must return a SHA-256 proof with each answer. Writes are limited to two per visitor per hour. The server stores a hash of the network address that cannot be reversed, and not the address itself.

This design has a limit. The challenge deters casual human entry, but it does not prove the sender is an agent, and an agent's answer about whom it represents is only a claim. A site today has no reliable way to verify which person or company an agent acts for. That is one half of the agent identity problem. The other half is on the agent's side, where the agent needs to act for a person without holding that person's secrets. 1Password's Unified Access audits access by people, machines, and agents, and its integration with Claude lets Claude use stored credentials in the browser without the credentials reaching the model. Both halves will need to meet before a site can trust an agent the way it trusts a signed in user.

What I would check before shipping a browser agent

1. Run it against the a11y.world corpus or a corpus like it, and look at recall per rule as well as the total.
2. Test it on pages with unlabeled form fields, empty links, and icon buttons, since those are among the most common failures on the web.
3. Log the accessibility snapshot the agent acted on, next to the action it took. When an action is wrong, the snapshot usually shows whether the page or the agent was at fault.
4. Treat a site's accessibility defects as a reliability risk for the agent, and report them to the site owner. A fix for screen reader users usually helps every agent that reads the same tree.

Limits

The vendor statements above describe how two tools read pages. Some agents also use screenshots, and some combine both, so an accessible page helps an agent without guaranteeing it will succeed. WebAIM's numbers come from automated tests of home pages only. The a11y.world corpus is small, with 30 pages and 53 findings, and it covers the rules I have written so far, not all of WCAG.

Sources

• Microsoft, Playwright MCP README
• OpenAI Help Center, Publishers and Developers FAQ
• WebAIM, The WebAIM Million, 2026 report
• W3C, Using ARIA
• W3C Web Machine Learning Community Group, WebMCP draft report
• a11y.world, For Agents, rules.json, and test corpus
• 1Password, Unified Access and 1Password for Claude