WebKit Says Agents Are Assistive Tech: The WebMCP vs ARIA Fight and Which Bet to Make
WebKit opposes WebMCP, Mozilla is neutral, one client ships. Use this surface-bet table to choose ARIA, WebMCP or both for each job your site lets agents do.
Go deeper. Build your own.
WebKit’s objection to WebMCP fits in one clause: “An agent acting on a user’s behalf is, in effect, assistive technology.” If that is true, the way to make a site work for agents is the way you already make it work for screen readers, through the page’s shared HTML and ARIA semantics, and a separate tool layer for agents is a detour.
Chrome’s team is betting the other way, with an origin trial that lets pages register typed tools for agents. So the WebMCP vs ARIA question lands on the site owner as a budget question: where do next quarter’s front-end hours go, into the accessibility tree that every client can read, into registered tools that one shipping client calls, or into both?
The answer this piece argues for is short. Fix the accessible path first for every job your site lets an agent do, add WebMCP as an overlay only where it describes the same action, and never let a job exist only as a tool. The decision table below makes that concrete by job type, and the re-check list tells you when to revisit it.
Where WebKit, Mozilla and the W3C TAG stand on WebMCP, June to October 2026
On May 28, WebMCP spec editor Dominic Farolino asked both non-Chromium engines for a position. WebKit answered first. In standards-positions issue #670, WebKit’s Mike Wyrzykowski wrote that “WebKit is opposed to this proposal due to the following concerns”, dated June 3 in UTC (GitHub renders it as June 2 in American time zones). The “position: oppose” label followed on June 11, and the issue was closed.
Screenshot: github.com, “WebMCP · Issue #670 · WebKit/standards-positions” (May 28, 2026), captured Oct 7, 2026.
The position is WebKit’s, Apple’s engine team; “Safari opposes WebMCP” is shorthand, not a quote. The reasoning goes well beyond accessibility. WebKit argues that when a site’s actions are hard for an agent to use, the gap is in the page’s own semantics, and the fix belongs in HTML and ARIA, “where the user, assistive technology, and agents all benefit.”
It says the origin list a tool is exposed to recreates “the ‘screen-reader-blocking problem’, but applied to AI agents”, because a site can give agents capabilities its human interface lacks or withhold them. It flags an unexamined cross-origin invocation path, notes that there is no consent or reversibility model for consequential actions (“readOnlyHint is advisory, toolautosubmit submits without review”), warns of a “personalization-to-fingerprinting” pipeline, and argues the work belongs with the HTML and ARIA groups rather than a machine-learning community group.
Screenshot: github.com, “WebMCP · Issue #670 · WebKit/standards-positions” (Jun 3, 2026), captured Oct 7, 2026.
Do not paraphrase this as “agents must use the accessibility tree.” WebKit’s claim is narrower and harder to argue with: improve the shared semantics so people, their assistive technology and their agents all get the same page. On June 17, WebKit’s Marcos Caceres went further and floated setting WebMCP aside for a new community group and a W3C workshop “Around the TPAC 2026 time frame maybe”.
Mozilla landed elsewhere. In mozilla/standards-positions issue #1412, Benjamin VanderSloot proposed “neutral” on June 1: WebMCP “opens a surface whose real-world dynamics leave too many open questions to wholeheartedly endorse.” The issue was closed with the “position: neutral” label on August 5; the issue timeline shows the label added on August 3.
Neutral is not support. The same comment says declarative WebMCP lets a site, with the user, block a prompt-injected agent, “However, this is no defense against a malicious site,” and that “The name is misleading,” since no MCP is involved.
Screenshot: github.com, “WebMCP · Issue #1412 · mozilla/standards-positions” (May 28, 2026), captured Oct 7, 2026.
Screenshot: github.com, “WebMCP · Issue #1412 · mozilla/standards-positions” (Jun 1, 2026), captured Oct 7, 2026.
The W3C Technical Architecture Group has its own design review, #1238. In its September 21 minutes, reviewer Christian Liebel recommends saying “no consensus”, and on October 6 the TAG said it is still “actively working on this review.” The Web Machine Learning Community Group, which owns the draft, resolved on August 20 to “Initiate wide review of WebMCP with the i18n and a11y groups.”
TPAC 2026 runs October 26 to 30 in Dublin, with WebMCP on the community group’s October 27 agenda. A meeting is not a decision; expect minutes, not a verdict.
On the Chromium side, the origin trial runs M149 to M156, and a September 28 request to extend it to M162 drew one approval, conditional on a summary of developer feedback. The Chrome Status entry still says “Proposed”, and it still shows Safari and Firefox as “No signal”, which is stale against both issues above.
One correction to a line that has been circulating: the ChatGPT desktop app’s built-in browser is not “the only production WebMCP client in the EU.” It is the only shipping WebMCP client anywhere, with “site tools” since August 25 per launch coverage, and OpenAI’s docs document no EU-specific WebMCP restriction. The confusion seems to come from Gemini in Chrome, which is reportedly still unavailable in the EU for reasons Google has not stated; it does not call WebMCP tools in any region, though Google said on May 19 that it “will soon” (Chrome for Developers’ I/O 2026 roundup). The WebMCP repo’s implementation status page lists the experimental callers.
What none of these documents says matters as much as what they do. A standards position is an engine team’s signal, not a promise about what its browser will ship or block. Mozilla’s neutral is not a quiet yes.
WebKit did not say agents may only use the accessibility tree. Nothing from Chrome says the trial will turn into a default-on launch, and the planned M157 launch has already slipped. Plan for all three engines to hold their current positions through at least the next re-check.
Two surfaces for one intent: the accessibility tree and the registered tool
Take one intent, “check whether my order shipped.” A client can reach it two ways. Through the accessibility tree, it reads what screen readers read: a heading, a labeled status region, a table with named columns, built from HTML elements and ARIA names, roles and states. Through a registered tool, it calls a function the page published with a description and an input schema, and gets fields back.
One intent, two surfaces, one outcome: the bet is about which path you keep healthy, not which one exists.
The accessibility tree has one big advantage: every client can use it today. Screen readers use it, and browser agents that read the DOM or drive the page with clicks benefit from it too. From the agent’s side, the desk-job inventory argues for the most precise tool first, and for reading, fetching a page as text beats driving it. A registered tool is the most precise surface of all, but only for clients that call it, which today means one desktop browser.
None of this is about being found or cited by AI answers; that is a different job, covered in the AEO classification sheet. And it is not a review of the browser agents themselves, which the agentic browsers review covers along with the injection risks they bring. This is the site’s side: which surface you maintain for the agents that arrive.
Maintaining the accessible path is unglamorous and concrete. Every control has an accessible name that says what it does, a role that says what kind of thing it is, and a state that changes when it changes. Errors are announced, not just painted red.
Status changes land in a live region. A form field’s label is tied to its input, so “Seats” never means the seat count in one place and the seat map in another. None of that is new work invented for agents, which is exactly WebKit’s point.
The surface-bet decision table, by job type
Fill one row per kind of job your site lets an agent do. Each cell answers three things: which browsers or clients can act today, what you maintain, and what a failure costs. The last column is the default bet for this quarter.
| Job type | ARIA-only bet | WebMCP-only bet | Both (ARIA first, WebMCP overlay) | Default bet this quarter |
|---|---|---|---|---|
| Read a status (order, ticket, booking) | Acts today: screen readers and every browser agent that reads the page. Maintain: a labeled status region, a live region for updates, semantic tables. Failure cost: low; a misread sends one customer to support | Acts today: ChatGPT desktop browser with site tools on, plus test clients. Maintain: a read tool, its schema, a trial token. Failure cost: medium; invisible to every other client, gone if the trial lapses | Acts today: all of the above. Maintain: the status region plus a read-only tool returning the same fields. Failure cost: low; the risk is the tool and the page drifting apart | Both |
| Fill a form (contact, booking, return request) | Acts today: any agent that can drive the page, and screen-reader users. Maintain: labels tied to inputs, announced errors, required states. Failure cost: low to medium; a wrong field shows up on review | Acts today: one shipping client. Maintain: tool attributes on a form whose human labels may rot. Failure cost: medium; the human path degrades, which is the parity problem WebKit names | Acts today: all. Maintain: one labeled form with declarative tool attributes, so the label and the tool description describe one action. Failure cost: low if both are reviewed together | Both, on the same form |
| Complete a purchase | Acts today: agents that can drive checkout, stopped by your confirm screen and fraud checks. Maintain: an accessible checkout with an explicit final confirm. Failure cost: high but familiar; the confirm screen is the gate | Acts today: one client. Maintain: a payment tool plus the consent and reversibility design the draft does not provide. Failure cost: high; a consequential action guarded by hints | Acts today: all. Maintain: two paths into one order API, with the tool stopping at your own confirm screen. Failure cost: high if the tool skips the confirm | ARIA-only until a second shipping client exists |
| Navigate content (docs, catalog, help) | Acts today: everyone, including text fetchers. Maintain: landmarks, headings, descriptive link names. Failure cost: low | Acts today: one client. Maintain: a search tool that repeats what links and fetch already do. Failure cost: wasted hours | Acts today: all. Maintain: a read-only search tool only where faceted search is hard to drive. Failure cost: low | ARIA-only |
Read the “WebMCP-only” column as the warning it is. In every row it reaches fewer clients than the other two bets and leaves the human path to drift, which is why the default is never WebMCP-only.
To fill your own rows, start from the jobs, not the pages. A booking site might have one “read a status” row for reservations and another for waitlists, because their failure costs differ. Write “acts today” from evidence you can point to, such as your logs or a client’s documentation, not from launch posts. Then write the maintenance cell in hours per quarter, even rough ones, because that is the number your manager will ask for.
The three-question bet rule
Run these three questions per row before you change the default.
1. Who are your users’ agents today? Check your server logs for the clients that already act on your site, and count WebMCP calls separately if you run the trial. If the shipping WebMCP client is a small share of your agent traffic, the accessibility tree is doing most of the work whether you planned it or not.
2. Can you keep ARIA and WebMCP describing the same action? Parity means three things: no tool exposes a capability the human interface lacks, the tool’s description and the control’s accessible name say the same thing, and one person owns both. If you cannot staff that, you are not ready for “both” on that row.
3. What breaks if the trial ends? Origin trials end. If the honest answer is “customers can no longer do X”, you have built a WebMCP-only path, whatever the plan said. The answer you want is “one client gets a slightly less precise route.”
Then apply the rule underneath all three: a tool is an overlay on a working accessible path, never a replacement for one. The hands-on version, with three first tools, their annotations and kill paths, is in the WebMCP registerTool playbook.
An illustrative ticketing site places its bets
A worked example, with every number illustrative. A regional event-ticketing site lists 24 agent-relevant actions: 4 status reads, 9 forms, 3 purchase flows and 8 kinds of content browsing. A keyboard and screen-reader pass finds 17 of the 24 working and 7 broken: an unlabeled seat picker, two forms whose errors are never announced, a status page built from unlabeled divs, and three filter controls with no accessible names.
The table sends the hours to those 7 first, estimated at 6 engineer-days, because each fix helps screen-reader users, every browser agent and any future tool caller at once. Only then does the site add a WebMCP overlay: a read-only “check my tickets” tool and declarative attributes on the refund-request form, both mirroring controls that now pass the accessible check. Checkout stays ARIA-only, behind its existing confirm screen. Browsing stays ARIA-only too; headings and link names already serve fetchers.
Four of the site’s rows in the dual-path form, after the fixes (illustrative):
| Action | Works by keyboard and screen reader? | ARIA name, role and state correct? | WebMCP tool? | Clients that call it today | Human confirm? | Kill switch | Bet |
|---|---|---|---|---|---|---|---|
| Check my tickets | Yes, after the status-page fix | Yes: labeled status region, live updates | Read-only tool | ChatGPT desktop built-in browser with site tools on | No, read only | Feature flag withdraws the tool; the page is untouched | Both |
| Request a refund | Yes, after errors are announced | Yes | Declarative attributes on the same form | The same single client | Yes, the person submits the form | Remove the attributes; the form still works | Both, on the same form |
| Buy tickets | Yes | Yes | None | n/a | Yes, the existing confirm screen | n/a | ARIA-only |
| Pick seats | Yes, after the picker gets labels | Yes, after the fix | None | n/a | Yes, inside checkout | n/a | ARIA-only |
The arithmetic is the argument. Six days of accessibility work reach every client today. The overlay, perhaps two more days, reaches one client today and more if the trial survives. Doing them in that order means neither bet is wasted if the standards fight goes either way.
Run the three questions on the purchase row and the result is clear.
The site’s logs show the shipping WebMCP client as a small minority of agent sessions. Parity would mean two paths into one order system, with a confirm step the tool could be tempted to skip. And if the trial ended, a WebMCP-only checkout would simply stop. Three answers, one verdict: ARIA-only until a trigger fires.
Quarterly re-check triggers for the surface bet
Put a recurring review on the calendar, and pull it forward if any trigger fires.
| Trigger | Where you would see it | What you change |
|---|---|---|
| TPAC outcome: the October 27 community group minutes, or a workshop on agents as assistive technology | W3C minutes for the Web Machine Learning group; the TAG review thread | If the draft moves toward shared HTML semantics, keep investing in labels and forms; if it adds a consent model, revisit the purchase row |
| Chrome Status change | Stage moves from “Proposed”, the M162 extension is decided, or the Safari and Firefox signals are updated | A shipping decision raises the value of the overlay rows; a lapse means auditing for WebMCP-only paths at once |
| A second shipping client | A browser or assistant documents calling WebMCP tools in production | Re-run question 1 with the new client’s traffic; consider “both” for rows still on ARIA-only |
| An engine revisits its position | New comments or labels on WebKit #670 or Mozilla #1412 | Re-read the concern list against your parity checks |
Sourced dates from the WebKit and Mozilla position issues, blink-dev, the TAG review and W3C minutes; the next scheduled point is TPAC.
How a surface bet goes wrong on a live site
| What breaks | Signal you would see | First action |
|---|---|---|
| A WebMCP-only flow loses its trial | Support tickets for a task that “used to work with my assistant”; no human path in the page | Ship the accessible version of the flow, then re-register the tool as an overlay |
| Tool and accessible control drift apart | Tool description and the control’s accessible name disagree in a side-by-side review | Make one owner responsible for both, and review them in the same pull request |
| A tool does what the human interface cannot | A capability appears in the tool list with no matching control on the page | Remove the tool or build the control; WebKit’s parity concern applies directly |
| Consequential tool skips your confirm | Orders or refunds logged with no confirm-screen event | Withdraw the tool and route the action through the existing confirm step |
| ARIA-only forms get mis-filled by agents | Spikes of submissions with values in the wrong fields | Fix labels and input purposes first; add declarative tool attributes only after |
| Hours sink into tools for one client | Tool maintenance grows while that client stays a small share of agent traffic | Freeze new tools until a re-check trigger fires |
Your visitors run a mixed fleet
The agents reaching your site will not agree on a surface. Some call tools, some read the accessibility tree, some fetch text and some click; one person may use three of them in a week. The site that serves that mix is the one where every surface describes the same actions and none is a private back door. That is the same discipline you would apply to your own agents: one inventory, one owner per entry, one review cadence, as in the weekly loop of agentic ops.
The next battleground for this mix is the chat window itself, where assistants now render controls inside answers; the interactive answer surface checklist covers that side. On your own pages, bet on parity and let the standards bodies argue about the rest.
FAQ
Does Safari support WebMCP?
No. WebKit, the engine behind Safari, formally opposes WebMCP in its standards-positions issue #670, labeled on June 11, 2026. Its reasoning treats agents as assistive technology and raises security, consent, fingerprinting and venue concerns. A position is a signal, not a shipping ban, but no Safari support has been announced.
Can AI agents use the accessibility tree instead of WebMCP?
Many browser agents already rely on the same structure screen readers use: element roles, accessible names and states from HTML and ARIA. A well-labeled page works for those agents and for people at once. WebMCP tools are more precise, but as of October 2026 only one shipping client calls them.
Should I build WebMCP tools or fix ARIA first?
Fix the accessible path first. Labels, roles, announced errors and a clear confirm step help screen-reader users and every browser agent today. Then add WebMCP tools as an overlay for actions that already work by keyboard and screen reader, and never let a task exist only as a tool.
Sources
- WebKit standards-positions, “WebMCP” issue #670 (opened May 28, 2026; oppose label Jun 11, 2026)
- Mozilla standards-positions, “WebMCP” issue #1412 (opened May 28, 2026; closed neutral Aug 5, 2026)
- W3C TAG design review #1238, “Incubation: WebMCP” (accessed Oct 7, 2026)
- W3C Web Machine Learning Community Group minutes (Aug 20, 2026)
- blink-dev, “Intent to Extend Experiment: WebMCP” (Sep 28, 2026)
- Chrome Platform Status, WebMCP feature entry (updated Sep 28, 2026)
- OpenAI, ChatGPT site tools (WebMCP) docs (accessed Oct 8, 2026)
- WebMCP implementation status (accessed Oct 8, 2026)
- Chrome for Developers, “15 updates from Google I/O 2026” (May 19, 2026)
- SEO Inc., “WebMCP Explained: What OpenAI’s New Standard Means For SEO” (Aug 31, 2026)
- Web Machine Learning, TPAC 2026 F2F agenda, meetings issue #39 (accessed Oct 8, 2026)
