WebMCP and Web Accessibility: The Conversation Nobody Is Having

Everyone is talking about WebMCP as a game-changer for AI agents and SEO. Chrome 146 Canary already has an early preview behind a flag. It’s co-authored by engineers at Google and Microsoft, and it lets websites expose structured tools directly to AI agents. Some have compared MCP to “the USB-C of AI agent interactions.”

But there’s a massive use case hiding in plain sight that nobody seems to be discussing: web accessibility.

WebMCP might be the most significant thing to happen to assistive technology users since ARIA became a W3C Recommendation (2014).

Let me explain why.

The Problem Today

Right now, a blind person using a screen reader navigates the web through the DOM: the document’s structure of headings, links, buttons, and form elements. When a site is built with proper semantic HTML and ARIA attributes, this works reasonably well. But here’s the uncomfortable truth: most websites are not built that way.

The WebAIM Million 2025 report finds that 94.8% of home pages have detectable WCAG failures. For screen reader users, this translates into broken navigation, unlabeled buttons, inaccessible forms, and constant guesswork.

Modern web applications increasingly rely on complex JavaScript-driven interfaces (dynamic filters, drag-and-drop interactions, and real-time updates) that are notoriously difficult to make accessible, even with the best intentions. For users who rely on switch access or eye tracking, every additional UI step is a physical cost. A flight booking that takes three minutes for a mouse user might take 45 minutes for a switch user. Not because they are slower, but because the interface demands dozens of sequential interactions that each require deliberate physical effort.

What WebMCP Shifts

WebMCP allows a website to publish structured, callable tools that AI agents can discover and invoke directly through an emerging standardized interaction layer in the browser. Instead of an agent struggling to interpret visual UI elements or messy DOM structures, the agent interacts with a defined schema of functions.

The core shift is this: WebMCP decouples the intent from the interface.

This reduces the visual interface as a bottleneck for accessibility. Think about what this means in practice:

Maria wants to book a train ticket from Stockholm to Gothenburg. Today, she navigates SJ.se by tabbing through navigation, finding the booking form, dealing with date pickers that may or may not be keyboard accessible, selecting seat preferences through a visual seat map she cannot see, and handling a multi-step checkout flow.

With WebMCP, the site exposes its core functionality through a structured schema. Maria tells her AI agent: “Book me a first-class window seat to Gothenburg on March 15th.”

Conceptual implementation of a book_trip tool:

{
  "name": "book_trip",
  "parameters": {
    "from": "string",
    "to": "string",
    "date": "ISO-8601",
    "class": ["first", "second"],
    "seat_preference": ["window", "aisle"]
  }
}

The agent calls the tool. Done. No DOM navigation. No inaccessible date picker. No visual seat map. The entire interaction happens through structured data.

Erik: C4 spinal cord injury, uses sip-and-puff

Erik controls his computer by sipping and puffing into a tube connected to a switch interface. Every click, every tab press, every form field is a deliberate physical action. Complex web interactions are exhausting.

Today, filtering products on an e-commerce site might require Erik to: navigate to the filter panel, open a category dropdown, select a category, set a price range with a slider he can’t use, apply filters, then repeat for additional criteria. That’s 15+ physical actions for something a mouse user does in three seconds.

With WebMCP, Erik speaks one sentence to his AI agent. One sip to confirm. The agent invokes a filter_products tool with the correct parameters instantly. What was 15+ physical actions becomes one.

Fatima: Deaf, communicates in Swedish Sign Language

Fatima encounters a customer support page with a phone number and a chatbot that requires audio verification. Neither works for her.

With WebMCP, the support site exposes a submit_support_ticket tool that accepts structured text input by design: issue type, description, preferred contact method. No phone call needed. No audio CAPTCHA. The structured tool does not care whether its input comes from speech, typing, or sign language translated through an AI agent.

Anders: Cognitive disability, finds complex forms overwhelming

Anders needs to file his tax return online. The Swedish Tax Agency’s digital service has dozens of fields, conditional sections, and technical terminology. Even with good accessibility implementation, the cognitive load is enormous.

With WebMCP, his AI agent can break the process into a natural conversation: “What was your income last year?” “Did you have any deductions?” The agent handles the complexity of mapping answers to the correct fields and calling the right tools in the right order. Anders handles the conversation.

The Reality Check

WebMCP is real and moving fast, but it is still in active incubation. As of early 2026, early browser previews exist and the specification is being developed within the W3C’s Web Machine Learning Community Group. The technical details (API surfaces, permission models, discovery mechanisms) are still evolving and may change significantly before standardization.

Browser vendors are also starting to ship agentic browsing capabilities alongside WebMCP. For example, Google has introduced “auto browse” in Chrome (currently a limited preview / initial rollout) that can carry out multi-step tasks on a user’s behalf.

But without a standardized interaction layer like WebMCP, these agents still have to interpret the page through the UI/DOM, which is fragile, error-prone, and highly dependent on how well the site was built. WebMCP gives agents a reliable alternative, and that same reliability could benefit assistive technology users too.

What matters more than the implementation details is the architectural shift. The specification introduces two critical pathways:

The Declarative Layer: Allowing even simple HTML to expose its intent to an agent with minimal overhead.
The Imperative Layer: Enabling complex, state-heavy web applications to provide direct functional access to their logic.

Both layers run client-side, respecting the user’s active session and security context. This is not about building a separate site for AI. It is about exposing the site’s existing capabilities in a machine-readable format that bypasses the friction of the visual DOM.

The specification explicitly emphasizes human-in-the-loop workflows. The agent acts on behalf of the user, with the user’s consent. This is not about replacing user agency. It is about removing unnecessary interface friction. For anything that changes state (payments, purchases, submissions), tools should require explicit user confirmation.

The Counterargument Worth Addressing

There’s a legitimate concern being raised in the WebMCP community: does this create a parallel system instead of fixing the existing accessibility layer?

The argument goes like this: if a function is missing for agents, it’s also missing for assistive technology users. The fix should be in the accessibility layer itself (better ARIA, better semantic HTML, better browser APIs), not in a separate channel that lets developers off the hook for building accessible interfaces.

This is a fair point, and it should not be dismissed.

But here’s the pragmatic answer: we’ve been waiting 25 years for developers to build universally accessible interfaces. The WebAIM Million numbers haven’t meaningfully improved in years. WCAG compliance remains the exception, not the norm. The European Accessibility Act and similar legislation may eventually change this, but legislation moves slowly and enforcement is uneven.

WebMCP does not replace the need for accessible visual interfaces, and we should keep pushing hard for them. But it offers a parallel path that works now, for users who can’t wait another 25 years for the web to catch up. Both efforts can and should coexist.

We’re Not the First to Notice

TetraLogical explored the intersection of the agentic web and accessibility in their article “Accessibility and the agentic web”, raising critical questions around testing and quality assurance of dynamically generated content. As AI agents mediate more web interactions, how do we ensure the quality and accuracy of the experience they deliver?

On the specification side, the WebMCP GitHub repository has an open issue specifically about accessibility considerations, and the W3C’s Web & AI Interest Group is actively debating how accessibility should be integrated into the standard. These conversations are happening right now, in the open.

This is exactly the moment to get involved.

What Needs to Happen

For WebMCP to fulfill its accessibility potential, we need deliberate action from multiple communities:

Web developers and site owners: When you implement WebMCP tools, you are not just building for AI agents. You are building an alternative interaction channel that can be life-changing for people with disabilities. Design your tool schemas with this in mind. Include text alternatives. Accept flexible input formats. Return structured, parsable responses.

Assistive technology vendors: Screen readers, switch access software, and alternative input devices need to integrate with AI agents that can leverage WebMCP. The combination of assistive technology + AI agent + WebMCP tools creates a pipeline that is more powerful than any of its parts alone.

The W3C working group: Accessibility must be a first-class concern in the WebMCP specification, not an afterthought. The Web Accessibility Initiative and the Web Machine Learning Community Group should be in active dialogue. Every design decision in the spec (tool discovery, permission models, error handling) has accessibility implications.

The accessibility community: We need to be at the table right now, while the standard is being shaped. The GitHub repository is public. The W3C group is accepting input. If we wait until the spec is finalized, we’ll be bolting accessibility onto a standard designed without us. Again.

The Bigger Picture

For over two decades, web accessibility has been fighting the same battle: convincing developers to build interfaces that work for everyone. We’ve made real progress with WCAG, ARIA, the European Accessibility Act, and growing awareness. But we’ve been working within a paradigm where the visual interface is the only interface.

WebMCP introduces a second channel. A structured, semantic, function-based channel that AI agents can use on behalf of users, regardless of how the visual UI is designed.

This does not replace the need for accessible visual interfaces. People who can and want to use websites visually should still have that option, and it should be accessible. But for the first time, there’s a realistic path to web interactions that completely bypass the visual layer when that’s what the user needs.

The irony is beautiful: a standard designed for AI agents might end up being one of the most important accessibility technologies of the decade.

Let’s make sure it is.