When Agents Use the Doorway Built for Blind Users

Every web page carries a second description of itself, one that most sighted people never see. The browser assembles it for assistive technology: a structured list of the elements on the screen, what kind of thing each one is (a button, a heading, a checkbox) and what it is called. A screen reader turns that list into speech. When a developer forgets to name a button, a blind user hears the word "button" and nothing more.

That list, the accessibility tree, now has a second reader. Playwright MCP, a Microsoft tool that lets AI models drive a browser, hands the model a snapshot of the tree so it can work out what to click. An unnamed button leaves the software guessing, much as it leaves the person listening.

The tree is in poor repair. When WebAIM scanned a million home pages this year, its tools flagged failures on 95.9 percent of them, up from the year before. For two decades the cost of a missing label has fallen on blind users, who are rarely in the meeting where the roadmap gets set.

Agents change who pays. When an agent stalls on that same button, a company running thousands of tasks notices by the next morning, and that company has a budget. One plausible future follows: delegation gives the web's doorways a user with money at stake, and every label repaired for the machine is repaired for the person too.

An October paper from the strategy team at the W3C, the web's main standards body, warns that "optimizing ARIA for agents may break the human experience." ARIA is the markup that labels elements for screen readers. The fear is that instructions written for models will clutter what blind users hear. The paper proposes a rule: "Where they conflict, the person's needs win." As a request for comment, the paper binds no one yet.

WebMCP, a quieter draft from a W3C community group, gives the machine a door of its own: sites can offer agents "tools" that skip the visible page. The draft describes users and agents collaborating in the same interface, and says assistive technologies could call those tools too. But nothing requires a tool to match what a person can do on the page, and its accessibility section is, so far, an empty heading. If agents get a side entrance, the front door loses its most demanding customer, and the money stops flowing toward the labels.

A side entrance would also miss what blind users have said they want. In a peer-reviewed three-week diary study, eight screen-reader users worked with a prototype agent on Windows desktop software. "I may not want it to do the whole task for me," one participant said. Another wanted the layout explained: "I can learn to do it myself the next time." The study did not cover the web, but the wish seems unlikely to stop at the browser. A side channel can finish a task for someone. It cannot show them where the controls are.

Inside a company, this will probably arrive as a routing decision. Accessibility usually belongs to a small team arguing for repairs against the pull of new features. If agents need the tree, that team picks up allies with budgets and dashboards. If agents get their own tools, the AI team builds them and the repair list stays where it was. So watch how an agent's failure on an unlabeled button gets filed: as an accessibility bug, or as a ticket for the AI team to work around. Only the first ends with the button named for the person using a screen reader.