Write the tool once

A thought experiment: that the agentic web — a direction, not yet a standard — may be the cheaper, more testable, better-incentivised route to accessibility, and a hypothesis about who gets to build the tools

For the eighth year in a row, WebAIM ran an automated accessibility evaluation of the top one million home pages on the web. The 2026 numbers are not a story of slow progress. They are a story of regression: 95.9% of home pages had detectable WCAG 2 failures, up from 94.8% the year before — reversing six consecutive years of small improvements. The average page carried 56.1 detectable errors, up 10.1% in a single year. Half of all home pages had form inputs with no labels. Nearly half had links that go somewhere but say nothing. A person using assistive technology should expect to hit an error on one in every twenty-six page elements. And WebAIM's own conclusion names a culprit for the reversal: "automated or AI-assisted coding practices ('vibe coding')."

Sit with that for a moment, because it is the uncomfortable place this essay starts from: right now, AI is making the web less accessible. Thirty-odd years of advocacy sit behind those numbers. The moral argument has been made, patiently and well, since before I started working with the web. The legal argument exists in most jurisdictions I care about. Neither has bent the curve.

This essay started at a dinner. On the evening before JavaZone 2026 I was seated next to Radostina — Ina — Tsvetkova, Senior Advisor in Digital Accessibility and Inclusive Design at NAV, the Norwegian Directorate of Labour and Welfare, and an invited expert in the W3C working group that owns WCAG itself. Her talk the next day was titled "Secure-by-Inclusion: Preventing Accessibility Barriers from Becoming Security Vulnerabilities," and its argument is the one she walked me through over dinner: the mechanisms we build to protect users — CAPTCHAs, multi-factor prompts, biometric logins, time-limited one-time codes, brittle account recovery — systematically exclude disabled and older users, and the exclusion becomes the vulnerability. In the words of her abstract: "Users facing accessibility barriers often adopt insecure coping mechanisms: they share passwords, delegate authentication to others, store credentials insecurely, rely on weaker fallback paths, or abandon security measures altogether. Each workaround is a predictable security failure caused not by user negligence, but by design choices that made the secure path inaccessible."

Delegate authentication to others. Hold that phrase; it comes back. I had come to the table from a different rabbit-hole. For the past year or so I have been building toward the other side of this: services that expose what they can do to AI agents as declared, typed capabilities — experiments on my own blog, and the direction I am pushing at Mynder where I am interim CTO, in Sunstone Atlas, in Synthesis — and an open protocol, KCP, for governing what an agent may know and do once it gets there, including who it may act as and how far. None of that is finished. It is where I am heading, and this essay is me thinking out loud about why. Somewhere between the main course and the coffee the two rabbit-holes met. Ina's field documents disabled users being forced, today, into informal, unscoped, unaudited delegation — handing a password to a relative — because the secure path was built for someone else's body. My field is, whether it meant to be or not, the engineering of formal, scoped, audited delegation. The thought I could not shake afterwards, and have not been able to put down since, is this: the way we are building the agentic web looks to me like a cheaper, more testable, and — for the people at Ina's end of the table — potentially far richer route to accessibility than the way the accessibility industry has been forced to work for thirty years. Not because anyone designed it that way. Because of what an agent needs.

A note on interest before anything else, and I will repeat it wherever it matters. KCP is not a product. It is an open specification under the Apache 2.0 license — its README says, in as many words, that it "remains an Apache 2.0 open specification proposed by eXOReaction AS" — and nobody pays anyone to use it. But I co-created it and I maintain it, which gives me an author's stake in seeing it adopted and a reputation tied to whether its ideas hold up. Separately, I hold a paid role at Mynder, and I build Sunstone Atlas and Synthesis, and all three stand to do better in a world where services expose declared capabilities the way I am about to describe. That is not a sales interest in the protocol. It is an author's and a builder's interest in the idea, and it is enough that you should check every claim against the public artifacts I link. What follows is not a recommendation I am pushing. It is something I noticed from where I sit, put forward to be examined, tested, and argued with — and if you are a disabled reader, I would rather you held me to the standard the accessibility community has earned the right to apply to anyone who arrives from the technology side with an idea about your life.

One more framing note, because it governs everything below. The agentic web I am describing — WebMCP, MCP reaching the consumer web, KCP, the whole notion of services declaring their capabilities to agents — is a direction, not an established standard. WebMCP is an origin trial. MCP on the consumer web is mostly absent. KCP is a proposal. What follows is a reflection on where that direction leads if it holds, argued as carefully as I can, and not a technical brief or a documented practice. Read it as a thought experiment with receipts.

Here is the idea, in four parts. Three I think hold up as arguments today; the fourth is a hypothesis, and I will keep calling it one.

(a) It is cheaper to build. Declaring a service's capabilities once, as typed tools, is less work than auditing and retrofitting every page, every state, every breakpoint of a visually rendered site — which is what accessibility remediation has meant since the 1990s.

(b) It is easier to test. A typed tool contract can be tested deterministically, fast, and without a browser. Rendering correctness — of which accessibility correctness is a subset — sits at the slowest, flakiest, most expensive layer of the testing pyramid, and the whole industry has known that for a decade and a half.

(c) The incentives are already pointed there. Services are building the agent door for reasons that have nothing to do with disability — agent reliability, agent commerce, not being left off the agentic web. The accessibility benefit does not need its own budget line. It rides.

(d) Hypothesis: the assistive tools get better, because they get written once. A switch-scanning agent, an AAC authorship-protection layer, whatever a specific disability community actually needs — built against a shared, typed capability declaration — is written once and works on every service that exposes tools the same way. Today an assistive tool has to contend with every individual site's bespoke, drifting DOM. That is N tools times M sites. A shared protocol collapses it.

Each of those needs an argument, and the last needs a warning label. But first the machinery underneath all four, because the idea only makes sense once you see what an agent is actually reading when it reads a web page.

The same tree

When a browser renders a page, it builds the DOM — and then it builds a second structure from it: the accessibility tree. MDN's definition is worth quoting because nothing about it is new: browsers "create an accessibility tree based on the DOM tree, which is used by platform-specific Accessibility APIs to provide a representation that can be understood by assistive technologies, such as screen readers." Every node carries a name, a role, a state, a description. This is the machinery WAI-ARIA feeds and that screen readers have consumed for decades. (One precision, because the ARIA spec itself makes it: some assistive technologies read the DOM's semantics directly rather than through the tree. What none of them read is the rendered pixels.)

Now look at what the current generation of agent browser tooling does. Microsoft's Playwright MCP server — one of the most widely used ways to give a language model a browser — describes itself like this: it "enables LLMs to interact with web pages through structured accessibility snapshots, bypassing the need for screenshots or visually-tuned models." Its lead feature bullets: "Uses Playwright's accessibility tree, not pixel-based input." "No vision models needed, operates purely on structured data." "Deterministic tool application. Avoids ambiguity common with screenshot-based approaches." Google's Chrome DevTools MCP server does the same, and this one I can verify first-hand, because it is the browser tool available in the environment where I am writing this. Its snapshot tool describes itself, verbatim: "Take a text snapshot of the target page based on the a11y tree… Prefer taking a snapshot over taking a screenshot."

So, without any speculation: the screen reader and the browser agent are two consumers of the same semantic layer. When a developer ships an unlabeled button, the screen reader announces "button" — and the agent sees an anonymous node it cannot confidently invoke. Every one of WebAIM's six dominant error types breaks both clients the same way. Every accessibility defect is now, mechanically, an agent-reliability defect.

The accessibility community wrote the specification for this eighteen years early. WCAG success criterion 4.1.2, "Name, Role, Value," normative since 2008, requires that for all user interface components "the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies." Gather information about. Activate. Keep up to date on the status of. That is the perceive–act–observe loop of every agent architecture of the last two years, specified as a web standard because blind users needed it. They were writing the functional requirements of a non-visual software client operating an interface on a human's behalf — which is what a screen reader is, and what an agent is.

I want to be precise about that claim's scope, because later I will show you the people building the agentic web rejecting a stronger version of it. The two clients perceive through the same layer and fail on the same defects. Whether an agent's tools also belong in that layer was argued out in public this year, and the answer was no — for reasons that turn out to matter enormously for claim (d). Hold that.

Three doors

Everything above is about reading a rendered page better. A page still gets built, a DOM still exists, an accessibility tree still gets derived from it, and two non-visual clients reverse-engineer the service's capabilities from that derivation. I have called this before a translation of a translation: the service knows what it can do; it translates that into pixels for sighted users with pointing devices; the screen reader translates the pixels' skeleton back into something structured. Doing the second translation more faithfully is what accessibility remediation is. It is also, precisely, where the entire old-school accessibility budget lives.

There are, right now, three ways for an agent to reach what a service can do. I think of them as three doors, and the whole idea turns on which door the money goes to.

Door one: read the rendering. The agent loads the page and reads its accessibility tree. This is Playwright MCP and Chrome DevTools MCP; it is what every agentic browser shipping today falls back to; and it is where all of the evidence above lives. It is also the only door the accessibility industry has ever had. Every audit, every ARIA retrofit, every overlay, every per-site fix is work done on this door.

Door two: the page annotates itself. WebMCP — the W3C community-group proposal from Google and Microsoft engineers, in origin trial in Chrome 149 and Edge 150 as I write — lets a page register tools in its own JavaScript (document.modelContext.registerTool()) or mark up an ordinary form with toolname and tooldescription, so an agent can call "add to cart" as a typed function instead of finding the button. This shortens the second translation without removing it, and it is page-bound by design: headless browsing is a listed non-goal, so are "fully autonomous workflows… where a browser UI is not present," and the goals include "Prevent web content disintermediation: Prevent disintermediation of web apps by backend integrations by adapting front-ends for use by agents, rather than replacing them" and, flatly, "The human web interface remains primary." Static manifests were considered and rejected because they cannot follow "the active page state or user authentication status." Chrome's documentation states the consequence: "Clients and browsers must visit a site directly to know if it has callable tools."

Read those goals again with the first half of this essay in mind. The reason WebMCP keeps the agent on the page is commercial: a service whose capabilities are a backend API is a service whose front end can be bypassed, and the front end is where the merchandising lives. That is a legitimate concern. It is also, exactly, the incentive structure that produced a web where ninety-six percent of front doors are broken — the visual rendering is the product, and everything non-visual is derived from it after the fact.

Door three: there is no page. A service exposes its capabilities directly as typed, described tools, and nothing is rendered for anyone. This is what the Model Context Protocol does natively: a client sends tools/list, gets back names, descriptions and JSON schemas, and sends tools/call. Nothing in the tools chapter or the transports chapter of the specification mentions a page, a DOM, or a rendering, because there isn't one. Google's A2A agent cards do the same for agents. And — interest noted again — the KCP manifests I help maintain do the same for knowledge and governed procedures: a knowledge.yaml at a repository root, or discovered through /.well-known/kcp.json, or distributed as a static catalog "independently of any running service," with an MCP bridge that answers tools/list and never touches a browser. KCP even has a name for door one in its own discovery vocabulary — web_traversal, glossed as "Playwright, headless browser" — and files it as a lower-provenance source than manual declaration. Reverse-engineering the rendering is, in the protocol's own taxonomy, the fallback.

Here is why door three is where this essay's idea lives. On door one, a screen reader and an agent reverse-engineer the same rendering. On door two, the rendering carries a machine-readable annotation of itself. On door three there is no rendering, so there is no translation of a translation — there is no translation at all. The service's declared capabilities are the artifact. A voice client, a braille display, a switch-scanning interface, an agent, and whatever modality nobody has invented yet each consume the same declaration and render it however serves that user. Every modality is exactly one step from ground truth, and the sighted user's pointing-device interface is one rendering among equals rather than the original everyone else derives from. That is the architecture the accessibility community has been asking for since the 1990s, arrived at by people who were trying to make agents reliable.

Three honesties, before I build on that. First, door three is where MCP lives today, and MCP lives mostly among developer tools and enterprise integrations; the consumer web — the checkout, the booking, the government form — is still door one with door two arriving. Anyone who tells you the page-free web is here is describing their IDE. Second, door three is already growing a rendering back: MCP Apps, the protocol's first official extension, lets a tool ship an HTML document rendered in a sandboxed iframe, and its specification contains no occurrence of the words accessibility, ARIA, screen reader, or keyboard; the issue asking for accessibility guidance has been open since February with no reply. What saves it for now is that the HTML is optional by rule. Third — and this is the one that shapes claim (d) — door three only helps a disabled user if something on their side renders the declaration for them. A screen reader will not do that, and the person who explained why is a blind screen-reader user. I will get to her.

(a) Cheaper to build

Start with what accessibility remediation on door one actually obligates you to do. Not fix the business logic — that part was fine. The obligation is to make the rendering of that logic faithfully reverse-engineerable, across every page, every interactive state, every breakpoint, every browser, and to keep it that way through every redesign. WebAIM's numbers are the price of that obligation, measured: 56 detectable errors per home page on average, on the top million sites, after thirty years. Pages that tried — the ones carrying ARIA — had significantly more errors than pages that didn't (59.1 against 42), because semantics applied badly are worse than none. That is not a story of lazy developers. It is a story of a layer that is structurally expensive to get right and stays expensive, because the artifact being audited was never designed to carry the meaning being audited for.

Now the door-three obligation. A service declares, once, what it can do: a name, a description, an input schema, an output schema, an annotation of what is safe and what is consequential. In the services I am moving toward this, that is a file, or a small server, per capability — and the point of the exercise is that it would be the same file whether the consumer is Claude, a switch-scanning agent, or a compliance auditor. There is no second rendering to keep in step, because there is no first one in the loop.

I want to be careful about the shape of this claim, because the "agentic web makes everything cheaper" genre is the lowest-trust content category in tech right now, and I have no interest in adding to it. So, the narrow version: the cost of accessibility does not disappear on door three; it moves — from the layer we are worst at verifying to a layer we are better at. Two things do not get cheaper. The business logic behind the tool surface is exactly as hard as before. And for years, serious services will run both surfaces — the human UI and the agent tools — and pay to keep them consistent; the transition costs more, not less, and anyone quoting you a near-term saving is invoicing you for the end state. What gets cheaper is the specific thing the accessibility industry has been paying for: the labor of making a visual artifact faithfully legible to a non-visual client. On door three that labor is the declaration, and the declaration is work you are doing anyway — which is claim (c).

One more honesty. I looked for a defensible number — a study showing that a declared contract costs some fraction of the equivalent rendering-plus-remediation — and did not find one I would stake this on. The "retrofit costs ten times more" figures that circulate are vendor content. So this is a practitioner's claim, from someone who has built the first and is building toward the second, and you should weight it as one. What I can point to is the next claim, where the industry's own evidence is unusually clear.

(b) Easier to test

The testing pyramid is fifteen years old and its lesson has not changed: put most of your tests at the unit and contract level, few at the UI level, because UI-level tests are the worst kind. Google's testing blog said it in 2015 under the title "Just Say No to More End-to-End Tests," on three grounds — slow feedback, flakiness, and the effort of finding the root cause when one fails — and concluded: "The exact mix will be different for each team, but in general, it should retain that pyramid shape." The following year the same blog measured the flakiness: "across our entire corpus of tests, we see a continual rate of about 1.5% of all test runs reporting a 'flaky' result," and "Almost 16% of our tests have some level of flakiness associated with them!" The canonical write-up on Martin Fowler's site puts it without hedging: end-to-end tests "are notoriously flaky and often fail for unexpected and unforeseeable reasons," they "require a lot of maintenance and run pretty slowly," and — the sentence that matters here — "Testing your user interface doesn't have to be done in an end-to-end fashion"; you can put "proper integration tests around your API" instead. And on contracts: "Automated contract tests make sure that the implementations on the consumer and provider side still stick to the defined contract."

Now notice where accessibility testing lives. It lives at the top of the pyramid, by necessity: it is a property of the rendered artifact, so it can only be verified against the rendered artifact, in a browser, with a real or simulated assistive client, across states and breakpoints. Automated checkers catch a fraction (WebAIM's are automated, and they only detect what is detectable), and the rest is manual screen-reader passes on a sprint cadence — the slowest, most expensive, least repeatable kind of test there is, done by the people whose time is scarcest. The accessibility community did not choose that layer. The architecture chose it for them. We test pixels as a proxy for testing capabilities, because the pixels are the only contract we published.

A declared tool surface is the contract, published directly, and it is tested the way contracts are tested: deterministically, in parallel, in milliseconds, with no browser in sight. Does the tool exist? Does its schema validate? Does calling it with these arguments produce this result? Does the annotation say it is read-only, and is it? Is the description complete enough for a client that has never seen the site to choose it correctly? Those are questions with yes-or-no answers, and they can run on every commit, in seconds — which is the shape of testing I am moving my own work toward. Nothing in that list requires a rendering, a breakpoint, or a screen reader — which means the accessibility correctness of the capability layer is testable at the base of the pyramid rather than the top. That is the real simplification: not less testing, but a testable contract replacing an untestable rendering as the thing you stake correctness on.

And the honest other half, because there is one, and it is new. With a UI you tested whether the button works. With a tool surface consumed by a model, you also have to test whether an agent, reading your descriptions, reliably chooses and composes the right tools — a statistical, model-versioned, nondeterministic property. Léonie Watson put the legal version of that problem better than I can: when the same prompt never yields the same output twice, "where does that leave the concept of representative sampling, and how can we be sure our digital products meet our legal obligations?" We are trading a testing problem we understand and hate for one we do not yet understand. I lean toward "the new one is more automatable" — a description is text, and text can be evaluated at scale — but that is a lean, not a finding, and it is the single strongest objection to this claim.

(c) The incentives are already pointed there

Here is the thing that separates this from every previous run at fixing the web. For thirty years the ask — label your controls, structure your content, make everything operable without a pointer — came from people whose market power could be, and was, ignored. The 2026 WebAIM numbers are what ignoring it looks like. Now the identical ask arrives attached to agent-mediated traffic and the revenue behind it. Sites will not label their buttons because it is right. They will label their buttons because unlabeled buttons don't convert when the customer's agent can't find them. And they will not declare their capabilities as tools out of virtue either; they will do it because a service the agents cannot use is a service that is not on the agentic web, and because the agent-commerce protocols being drafted by payment networks and platforms are, as far as I can read them, written in the vocabulary of declared capabilities, not rendered pages.

Which means the accessibility benefit is not a separate line item competing for priority against features. It rides. I can show you what that looks like from the inside, and this is where my interest matters most, so weigh it. Across KCP's quarter-megabyte specification, its README, and its standards proposal, the words "accessibility," "disability," "screen reader," and "assistive" appear exactly zero times — re-checked this week against the current head of the repository — and I can confirm from the inside what the grep suggests from the outside: none of it was designed for disabled users. It was built for agent reliability, auditability, and tool interoperability — the reasons the people adopting it actually have — and it arrived, unbidden, at scoped capabilities, fail-closed boundaries, and modality-independent audit trails: the trust infrastructure a person who cannot watch the screen has always needed before they could safely delegate. Nobody working on KCP set out to do accessibility work. We did it anyway, because an agent needs what a blind user needs, and the agent was who we were building for. And the incentive runs on the security side too, which is Ina's point turned around: an organization that has a formal, scoped, audited way for a user to delegate — to an agent, under a declared boundary — has removed one of the workarounds her talk catalogues. The compliance budget and the security budget are already paying for the door. The accessibility benefit walks through it.

The Linux Foundation's Agentic AI Foundation — to which KCP is submitted, a second and smaller interest, so noted — published the same observation from the MCP side in June, in an essay titled "Native speakers: why AI's most powerful users are blind": "Accessibility means both channels are complete. A flawlessly conformant interface is still a dead end for an agent-mediated user if the operations aren't in the tool surface." The curb-cut effect is usually offered as an analogy. This is not an analogy; it is the same artifact, consumed twice.

There is a counter-incentive, and I named it under door two: the service whose front end is the product will resist door three, because a tool surface strips the merchandising. WebMCP's authors wrote that resistance into their goals. I take it seriously. It means the services most likely to reach door three first are the ones where the front end was never the product — infrastructure, B2B, government, compliance, the services I happen to build — and the consumer checkout comes later, through door two, with the human interface "primary." I do not think that reverses claim (c). I think it sets its order.

(d) Hypothesis: write the tool once

This is the claim I was still turning over on the train home, and it is the one I want to state most carefully, because it is the sharpest and the least proven.

Consider how an assistive tool is built today. The clearest precedent is the oldest: JAWS, the dominant Windows screen reader, has shipped for decades with per-application script files — Calc.jss for the calculator, Notepad.jss for Notepad — because, as an AccessWorld primer put it in 2003, "A JAWS script is merely a bridge between the screen reader and the mainstream application." One bridge per application, written by the vendor or the community, maintained as the application changes. On the web the same shape reappears at every scale: the screen reader's heuristics for a thousand common widget patterns; the voice-control tool's fallback from names to numbers to a grid when the names are missing; the overlay industry, which sells a JavaScript snippet that tries to patch each site's DOM at load time and is condemned by roughly a thousand practitioners in the Overlay Fact Sheet because "no overlay product on the market can cause a website to become fully compliant with any existing accessibility standard." Whatever you think of any one of these, they share an economics: every tool must contend with every site's bespoke, drifting rendering. N tools times M sites, each pairing its own integration burden, each one decaying as the site redesigns. This is why assistive technology is expensive, why it lags, and why so much of the field's effort goes into coping rather than into what a specific community actually needs.

Now the hypothesis. On door three, the site's side of that integration is the same declaration for every consumer. An assistive tool built against the protocol — not against any site — is written once, and works on every service that exposes tools that way, with no per-site integration cost, and no decay when the service redesigns its human interface, because the human interface is not in the loop. Concretely: a switch-scanning agent that presents a service's declared tools as a short, ordered, scannable list, executes the chosen one from a single switch press, and reads back the result — written once, usable on every door-three service. An AAC layer that takes a single expressed intent, assembles the multi-step flow across whatever tools exist, and holds the whole thing at prepared until the user's own selection commits — written once. A voice client that never needs "Show numbers" or "Show grid" because the tool names are the interface. Whatever the cognitive-accessibility community decides an intermediary should do — written once. The specialist effort goes into the tool's quality for its community, not into keeping up with a million DOMs. That is the same "N×M gets absorbed" argument people make about generic agents and multi-site composition, applied to a much narrower and more consequential question: who builds disability tooling, and how far one person's work reaches.

Here is why it is a hypothesis and not a claim, and I want to give the evidence its full weight in both directions.

For it: the architecture is real and shipping, at least in developer tooling (door three exists there; MCP clients already consume any MCP server with no per-server code). The convergence it depends on has been noticed by the people building assistive technology — I will show you the record in a moment. And the interaction-economics research points the same way: Google's SpeakFaster work with eye-gaze typists with ALS saved "57% more motor actions than traditional predictive keyboards," which is the shape of gain an intent-once-execute-many tool would deliver for action rather than text.

Against it, or not yet for it: I could find nobody actually doing this — no assistive-technology vendor building against MCP or WebMCP rather than against sites. The strongest current signal is Vispero's AI agent for JAWS, which Léonie Watson reported in August is being built to ship inside the screen reader, and which she has pointed at WebMCP. But read the mechanics as reported: accessibility tree plus screen capture plus coordinate clicking when the software exposes nothing better. That is door one. It is evidence that the vendors are building agents; it is not yet evidence that they are building them against a typed protocol, and Watson's suggestion is a comment in a public thread, not a roadmap. Then there is the plural problem: "write it once" assumes one protocol, and today there are at least three — WebMCP for annotated pages, MCP for page-free tools, KCP for governed knowledge and procedures, A2A for agents — so the honest near-term version is "write it once per protocol," which is a small number rather than one, but not one. And finally: a protocol lowers the cost of building a tool. It does not decide what the tool should do. That decision belongs to the community the tool is for, and if door three simply lets more people like me build more things for disabled users without them, it will have reproduced the overlay industry's original sin at a new layer. I would rather say that now than have it said to me.

So: hypothesis. The most testable one in this essay, and the one I would most like to be shown wrong about in public, by someone who has built the tool.

The audit channel you never knew you had

One more piece of machinery, because all four claims end at the same place: a user who has handed a task to an agent, and now has to trust what it did.

When a sighted user delegates a task to an agent, they lose something they never had to think about: the ambient audit channel of watching the screen while things happen. A blind user never had that channel. Every delegating user of the agentic web is, structurally, in the position blind users have always occupied — trusting a mediated account of what was done on their behalf. Which means the governance disciplines that make delegation safe — action envelopes that fail closed, capability grants scoped per task, audit trails readable after the fact in any modality — are not enterprise compliance features that happen to help disabled users. They are the generalization of what non-visual computing always required.

And here is the phrase from dinner. Ina's abstract lists, among the coping mechanisms an inaccessible secure path forces on disabled users, that they "delegate authentication to others."

Read that as an engineer. It describes delegation with no scope — the relative who has your password can do anything you can do; no ceiling — there is no "read-only" mode for a shared credential; and no audit — nothing records what was done in your name, by whom, or what they declined to do. That is not a user's failure. It is, in her framing, "a predictable security failure caused… by design choices that made the secure path inaccessible." It is also, precisely, the threat model the agentic-governance work was built to answer: delegation that is scoped, has a ceiling, and is recorded. Disabled users are not waiting to be handed delegation by the agentic web. They are already delegating, informally and unsafely, because the alternative was exclusion. The question this approach answers is not "should they delegate?" — it is whether the delegation they already do gets a declared boundary and a log.

The doors make this concrete. On door two, the trust model is explicitly visual — Chrome's WebMCP documentation puts it in one sentence: "Tools execute on your webpage visibly, so users gain trust that tasks are completed as expected." That is the sighted user's ambient audit channel, rebuilt as a product feature, for the users who already had it. On door three there is no page to watch; the MCP specification asks hosts to "insert clear visual indicators when tools are invoked" and to "present confirmation prompts," and says nothing about what the user who cannot see the indicator gets instead. The further you go from the page, the more the trust question has to be answered by a record rather than by watching — which is the question non-visual users have been answering for thirty years.

Interest noted again: the example is one I helped write. KCP's skills carry an action_scope with an explicit deny — in the release's own words, "an explicit negative scope… meaning 'never, regardless of any allow'," evaluated deny-first, fail-closed — alongside an authority ceiling (observe < explain < suggest < prepare < commit) where "the lowest still wins": an agent declared at suggest cannot be escalated to commit by any grant anywhere in the stack. "A deny is never grantable — a deny-hit raises a notify-only prohibited-attempt event; no response to it enacts. The only way past a deny is a superseding, reviewed, signed manifest version." A refused attempt becomes a row in a structured table (prohibited_attempt_events, spec §17), with the matched rule named. That is a replacement for the ambient audit channel — not watching pixels move, but a machine-readable record of what was attempted, what was allowed, what was refused and under which declared boundary, equally legible through a dashboard, a terminal, or a screen reader. A refusal log you can read instead of a screen you must watch.

And its boundary: this matters where a user has delegated a multi-step action. Where the barrier is content — a missing caption, a wall of dense text — governance governs nothing, and I will say so when we get there.

Where the idea holds, population by population — and where it doesn't

An idea that claims to serve "people with disabilities" as one group is already wrong. So here is the idea tested against six populations, asking each the same three questions: What is broken today? What does the agentic web — doors one through three — mechanically change? And what does trust rest on once the task is delegated? The table is the claim; the paragraphs are the evidence, including where the cells are weakest.

Blind and low-vision users. Today: the numbers this essay opened with are this population's daily commute. The mechanism: the strongest case, and not an analogy — shared substrate, shared failure modes. A July 2026 arXiv paper ("MCP-Driven Accessibility Tree Standardization for AI-Powered Screen Reader Agents") proposes making the convergence official — an MCP layer exposing "ARIA-aligned roles, labels, states, and focusable-element hierarchies" to LLM-based assistive agents — and it is a conceptual framework, not an implemented system; worth saying plainly. The more important development is a correction to how I had been thinking about the last mile, and it came from Léonie Watson — a blind screen-reader user and a member of the W3C Advisory Board — in WebMCP's own issue tracker. There is a direct model, in which the screen reader itself reads a page's tool declarations, and an indirect model, in which an agent acts on the screen-reader user's behalf. The direct model does not work, and not because of a gap ARIA could close: "Screen readers are essentially reactive. They expose what's in the accessibility tree as the user navigates the page. They don't make decisions about which actions to take, construct arguments, or how to interpret structured data… This isn't a gap that can be closed with ARIA or the AOM, it's a fundamental difference between a screen reader and an agent." The benefit, she concludes, "has to flow through agents not through the screen reader directly." That sentence is the constraint on claim (d): the write-once tool for this population is an agent, not a screen-reader plug-in — and the agent that ships inside JAWS is the first candidate. After delegation: this is the one population for whom delegating removes nothing, because the ambient audit channel never existed here. What the governance layer changes is the quality of the mediated account: a fail-closed envelope declared before the fact and a structured refusal log after it — rows a screen reader traverses exactly as a dashboard renders them. Secondary reporting on the JAWS agent describes it pausing before high-risk actions to narrate and ask permission — the confirmation step kept on the user's side of the line, which is what an authority ceiling declares in advance rather than leaving to the agent's manners.

Motor disabilities — switch access, sip-and-puff, scanning. Today: a switch user operates the web through sequential scanning; Apple's documentation: "Item scanning highlights items or groups on the screen one at a time," and one or two switches select. When a page doesn't expose discrete items, Switch Control degrades to point scanning — crosshairs to raw coordinates — and a multi-step flow becomes an ordeal of linear traversals. The mechanism: an agent needs precisely what item scanning needs — a finite, enumerable list of discrete, well-bounded, programmatically actionable targets — which is why the Chrome DevTools snapshot assigns every element a unique identifier and Playwright MCP calls its approach "deterministic." An agent degrades from semantic invocation to pixel-clicking exactly where Switch Control degrades to point scanning. On door three the parallel becomes identity: a service's tools/list is a scan list, short and ordered and typed, with nothing to degrade to. One honest exception: target-size requirements — the 24-pixel minimums tremor and eye-tracking users depend on — have no agent analogue; the convergence is about semantics and structure, not geometry. After delegation: the economics invert — one expressed intent replaces the hundreds of scan-and-select cycles a checkout costs today — which makes this a population that will actually delegate, which makes the trust question live. The record of what was done and refused is discrete, ordered text — the shape switch navigation is built for — and the authority ceiling means the confirmation a user keeps for themselves cannot be escalated away by any grant. The switch press remains the commit.

Voice control. Today: a voice-control user speaks the names of controls, and WCAG 2.5.3 exists because this breaks when visible label and accessible name diverge: speech-input users "will be unsuccessful… because the visible label spoken by the users does not match (or is not part of) the accessible name." Apple Voice Control's fallback ladder is the same as switch access: name; failing that, "Show numbers"; failing that, "Show grid." The mechanism: an agent told to "click Submit" grounds a spoken reference to a named element and fails identically when the name is missing or wrong. On door three the tool name is the command, and the ladder has no lower rungs. After delegation: today, recovering from a misfired interaction means re-dictating navigation, command by command. Against a structured audit trail it becomes one question — "what did you do, and what did you refuse?" — answered from a log that is text, and therefore speakable.

Speech disabilities and AAC users. Today: every selection is slow and effortful; cost per interaction, not semantics, is the binding constraint. The mechanism: different from the shared-tree story, and I want to be honest about that — this is interaction economics, not shared infrastructure. Google's SpeakFaster work with eye-gaze typists with ALS saved "57% more motor actions than traditional predictive keyboards," with text entry 29–60% faster; the agentic model — express an intent once, and an agent performs the ten-step flow — is the same keystroke economics applied to action instead of conversation. After delegation: the trust question has a sharper edge here than anywhere, because the AAC research community has already articulated the condition: in the CHI study titled "The less I type, the better," AAC users welcomed the saving of "time, physical and cognitive effort" while insisting AI-generated output "reflect their own communication style and preferences." The user, not the agent, must remain the author — and an "after" that slides from amplifying a person's intent to ventriloquizing it has failed this population whatever it saved. This is where a declared authority ceiling reads as if designed for the requirement, though it wasn't: pin the agent at prepare, and every flow is assembled but nothing enacts until the user's own action commits it — agency preserved at exactly one selection's cost, by declaration rather than by the agent's good behavior. I flag that mapping as my design inference, not something any AAC study has evaluated — and as the clearest example of a write-once tool this essay can imagine, which is exactly why it must be an AAC community's decision, not mine.

Cognitive and learning disabilities. Today: the W3C's COGA guidance asks for eight things, about content and comprehension: help users understand, help users find, use clear language, help users avoid mistakes, help users focus, don't rely on memory, provide help, support personalization. The mechanism: here I have to slow down, because a page can be perfectly semantic and still cognitively hostile — the accessibility tree delivers none of COGA's content qualities, and neither does a tool schema. There is an indirect form I believe cautiously: an agent that executes a multi-step task removes the maze and the overload — functionally a memory and executive-function prosthesis, mapping onto perhaps four of COGA's eight objectives. I can point to no research on agents and cognitive accessibility specifically. Plausible, unproven. After delegation: the weakest "after" of the five where one exists: delegation has its own cognitive costs — trust calibration, verification, recovering from an agent's mistake — and a structured refusal log only helps a user who can consume it. COGA's demands for clear language and low memory load apply to the audit trail itself, and nothing in the governance layer guarantees them.

Deaf and hard-of-hearing users. Today: the barriers are media and language — missing captions, missing transcripts, missing sign-language interpretation, dense text for people whose first language is a signed one. The mechanism: approximately nothing, and I would rather say so than force the pattern. An agent does not need captions to call a tool, and a capability declaration captions nothing. Worse, the obvious "AI fixes this" move is explicitly rejected by the best current guidance: W3C states that "automatically-generated captions do not meet user needs or accessibility requirements, unless they are confirmed to be fully accurate," illustrating with a recipe video where "broil on high for 4 to 5 minutes" became "broil on high for 45 minutes." After delegation: there is no honest "after" here, and nothing in this essay's approach touches it. If this piece claimed universal benefit, this population would be the counterexample. So it doesn't claim that.

Honestly tallied, then: the idea holds for operability — perceiving and acting on interfaces — and the trust machinery holds wherever multi-step action is delegated. It does not extend to understandability or media equivalence. A strong pattern, not a universal one, and an idea about part of the problem.

Somebody set out to do this — and was told no

I said the convergence had been noticed by the people building assistive technology. Here is the record, and it is the best evidence in this essay for claim (d) — as well as its most important constraint.

WebMCP's explainer lists "Improve accessibility through agents" among its goals, and in the same breath draws a line: WebMCP "is not designed for ingestion by accessibility technology, nor is it designed to interact directly with a page's accessibility tree; rather, it enables agents to act as highly capable intermediaries." That sentence exists because of an argument. In February, someone opened an issue in the WebMCP repository titled "Redundancy with the accessibility tree," and made the case the first part of this essay makes: the accessibility tree already is a machine-readable description of a page's action space; assistive technology already uses it to act; "an AI agent can use the same interface. No additional protocol is needed"; and a separately maintained tool registry "can and will" drift from the tree. Twenty-nine comments later, in August, the Chrome editor closed it as not planned: no browser, Apple included, will let WebMCP contribute to the accessibility tree.

The reasons are the ones this idea has to carry. A Chrome engineer reported that the W3C conversations were "trending against reusing accessibility trees and ARIA tags for AI agents, as this could actually result in a worse outcome for human users of assistive software" — if agents consume ARIA, developers will tune ARIA for machines over humans, and sites that use ARIA patterns to detect bots will block screen-reader users along with them. The editor's summary: "These simply are not the same thing, and they are not directed at the same users, technology, or sinks." And then the resolution came from the accessibility side, from Léonie Watson, in the direct/indirect distinction above: the shared tree is the right substrate for perceiving a page and the wrong place to put an agent's tools, not because agents and disabled users need different things, but because a screen reader is not an agent. The benefit for screen-reader users is real and it flows through an agent. The Chrome editor's reply: "I couldn't agree more."

Read that as a builder. The convergence was noticed, proposed as a design principle, argued for six months by browser engineers and a blind standards veteran, and declined — in favour of exactly the shape claim (d) needs: the disabled user's gain is delegation; delegation runs on declared capabilities; and the thing that consumes the declarations on the user's side is an agent built for that user, not the screen reader carrying a second job. The standards body did not reject the write-once tool. It told us what the write-once tool has to be.

The counterargument I have to take seriously

There is a second school of agent design that reads pixels, not trees. Anthropic's computer-use tooling gives the model "screenshot capabilities and mouse/keyboard control"; OpenAI's computer-using agent is likewise vision-first. If vision models get good enough, an agent could cope with an inaccessible page the way a sighted human does — by looking at it — and claim (c) weakens, because agents would no longer need what disabled users need, and claim (a) weakens with it, because nobody would need to declare anything.

Three things make me think the structured path still wins where it matters. First, the tools built specifically for the web chose the tree, and say why: determinism, no ambiguity, no vision model in the loop, less cost. Second, a screenshot lacks the semantic roles and relationships, so a vision agent must reconstruct them probabilistically — the lossy reverse-engineering screen readers have been forced into for thirty years, with the same failure modes. Betting on vision agents is betting that translation-of-a-translation, done by a bigger model, stops being lossy. It has never been true before. Third — the detail I find most persuasive — assistive technology already runs both strategies in the same order agents do. Apple's VoiceOver Recognition uses on-device machine learning to recognize images and text "where VoiceOver support—like alt text or ARIA labels—is missing." And the JAWS agent, as described in the reporting I could find, does the same: accessibility tree first, screen capture alongside, coordinate clicking when the software exposes nothing better. Semantics first; vision as the fallback. The two fields have converged on the same degradation ladder. What door three offers is a floor under the ladder: a service that declares its tools cannot fail the way a page fails, because there is no rendering to fail.

What I am watching for

The accessibility community has earned its skepticism of exactly this kind of essay, and I am close enough to the kind of author it has learned to be skeptical of — someone from the technology side, with a protocol he helped write, suggesting a new layer might fix an old problem — that I should be held to the same standard. It spent years fighting overlay companies who made that promise for money; Adrian Roselli's standing rebuttal is titled, without hedging, "No, 'AI' Will Not Fix Accessibility." And Watson, who has thought about the agentic web from inside both communities, poses the question this essay cannot yet answer: if organizations replace their websites with agentic interfaces, "will that help or hinder accessibility?"

So let me state the idea at its narrowest, which is also its strongest. Agents don't fix inaccessible pages; agents fail on inaccessible pages, and that failure gives the people who build pages a selfish reason to fix them. Door three would remove the page from the loop for the users who can delegate, and the work of building it is work the service would be doing anyway, if the direction holds. A tool built against the declaration is written once. That is the whole claim, and every verb in it is conditional. Here is what would sour it.

The two-tier web, which is now a stated architecture. WebMCP is, by design, a second description of a page maintained alongside the accessibility tree, in separate code, for a separate consumer, with the human interface declared primary; the issue that pointed out those two descriptions "will diverge over time" was closed without that point being rebutted. The editors' reason is a good one — protecting human users of assistive technology from ARIA tuned for machines — and I take it. But it means every gain in this essay accrues to the delegating user, and today that is nearly nobody. A clean tool surface over a rotting interface strands everyone who is not yet delegating. One source, two renderings, kept in step by something other than good intentions — or the drift the issue predicted.

Door three growing its rendering back. MCP Apps is six months old, shipping in real hosts, and its specification does not contain the word accessibility. WebMCP's specification has an "Accessibility considerations" heading with nothing under it. Both are drafts and both can be fixed; the accessibility community knows better than anyone what it costs to fix them later. And quantity is not quality: WebAIM found pages with ARIA carry more errors than pages without, and the same will be true of tool manifests — the ones my own ecosystem ships every bit as much as anyone else's.

The order of adoption. The services with the strongest reason to reach door three first are the ones where the front end was never the product. The services where an inaccessible front door does the most damage — the benefits portal, the health booking, the tax form — are neither commercial nor quick, and they are the ones Ina works on. The inaccessible login that forces someone to hand over a password is, very often, a public one. If the agentic web reaches the checkout years before it reaches the benefits portal, the approach in this essay will have served the market before it served the people this essay is about — and the informal, unaudited delegation her talk describes will go on exactly as before, at the doors that matter most. I do not have an answer to that. I have a preference for saying it.

Who builds the tool. Claim (d) says the specialist tool gets written once. It does not say by whom. If a shared protocol simply makes it cheaper for people like me to ship tools for disabled users without them, it will have rebuilt the overlay industry one layer down, with better plumbing. The protocol is the cheap part. It always was.

Thirty years of asking politely produced a web where ninety-six percent of front doors are broken, and the first year of AI-assisted development made it worse. I don't expect the agentic web to be built out of virtue either. I expect it to be built out of incentives — and, if this direction holds, for once the incentives point at the same infrastructure the politeness always asked for, one door further from the page. Whether a tool written once against that infrastructure is actually better for the people at Ina's end of the table is the part I am least sure of, most interested in, and least entitled to decide. If you have built such a tool, or you are the person it would be for, I would rather hear where this is wrong than be agreed with.