# WebMCP vs Accessibility: Do You Need Both? (Yes, But Not Why You Think) *The internet lost its mind over this question. Here's the actual answer.* --- When Google dropped the [WebMCP Early Preview](https://developer.chrome.com/blog/webmcp-epp), a predictable fight broke out on Hacker News. One camp said "just use accessibility standards, we don't need another Google thing." The other camp said "a11y is for humans, WebMCP is for agents." Both camps are wrong — and both are right. I've spent the last few weeks testing WebMCP implementations across dozens of sites with [WebMCP Verify](https://webmcpverify.com). Here's what I've actually found about how these two standards interact, where they overlap, and where the gap between them is wider than anyone on HN seems to realize. ## The "Just Use Accessibility" Argument The case sounds reasonable: ARIA labels describe what buttons do. Semantic HTML tells machines what content means. Screen readers already navigate sites programmatically. So why do we need *another* standard for machines to interact with websites? Here's a real example. Take a flight booking form with proper accessibility: ```html ``` A screen reader can navigate this perfectly. An AI agent? It *can* fill in the fields and click submit — by actuating the DOM, essentially pretending to be a human clicking around. This works... sometimes. It's slow, brittle, and breaks the second the site redesigns the layout. Now here's the same form with WebMCP: ```html ``` The difference? The agent now knows this form is a *callable tool*. It has a name (`searchFlights`), a description explaining what it does, input validation rules, and a clear action endpoint. It doesn't need to "figure out" what the form does by reading labels — the developer told it explicitly. ## What Accessibility Actually Does (and Doesn't Do) The accessibility tree — the browser's internal representation of page elements for assistive tech — is genuinely powerful. It tells you: - **What's on the page** (text, images, headings, landmarks) - **What each element is** (button, link, checkbox, slider) - **What state it's in** (checked, expanded, disabled) - **Basic relationships** (this label belongs to that input) What it *doesn't* tell you: - **Why the form exists** (is it a search? a checkout? a support ticket?) - **What happens when you submit** (does it return data? start a process? charge money?) - **What the valid inputs are** (business rules, not just HTML types) - **Whether the action is safe** (read-only lookup vs. irreversible purchase) That last point matters more than people think. When an AI agent fills out a form, it's guessing at intent. The accessibility tree says "here's a submit button." WebMCP says "this tool searches flights — it's read-only and safe to call." The [WebMCP spec](https://github.com/webmachinelearning/webmcp) is explicit about this: it enables "higher-level actions" that go beyond what the accessibility tree provides. The spec authors (from Microsoft and Google) specifically call out that *"much of the challenges faced by assistive technologies also apply to AI agents that struggle to navigate existing human-first interfaces."* ## The Real Gap: Intent vs. Structure Here's the core insight that both HN camps missed: **accessibility describes structure, WebMCP describes intent.** | Aspect | Accessibility | WebMCP | |--------|--------------|--------| | "There's a text input here" | ✅ | — | | "This input expects an airport code" | Partial (via labels) | ✅ (via schema) | | "This form books a flight" | ❌ | ✅ (via tool description) | | "Submitting will charge your card" | ❌ | ✅ (via `destructiveHint`) | | "This action is read-only" | ❌ | ✅ (via `readOnlyHint`) | | "This form needs authentication" | ❌ | Partially (via context) | A real-world scan makes this concrete. When I [scanned mdconvrt.com](https://webmcpverify.com) on WebMCP Verify, it scored 28/30 on AI Discoverability (Schema.org, meta tags, LLMs.txt — the "structure" layer). But it scored 0/10 on Best Practices (tool naming, descriptions, input schemas, annotations — the "intent" layer). Good structure, zero intent. That's a site that a screen reader can navigate but an AI agent can't meaningfully act on. ## Where A11y and WebMCP Actually Overlap ![WebMCP Verify full report showing discoverability checks](https://photo.webmcpverify.com/blog-images/report-full-mdconvrt.jpg) *Semantic HTML and structured data — core to both accessibility and WebMCP agent discoverability.* ## The Accessibility Crowd Has a Point Though The critics aren't totally wrong. There's a real risk of WebMCP becoming an excuse to ignore accessibility. "We built for agents, who needs screen readers?" is a terrible take, but I guarantee someone will say it. The HN thread had a sharp observation: *"If accessibility features were good enough at describing the functionality and intent, you wouldn't need a separate WebMCP."* True. But they're not, and pretending otherwise doesn't help anyone. There's also the Semantic Web déjà vu argument: nobody will implement this because it only benefits others (agents, competitors, scrapers). This is the strongest critique, and it's the one I think WebMCP actually has an answer for. ## Why "Nobody Will Implement This" Is Wrong This Time The Semantic Web (RDF, OWL, microformats) tried to make the entire web machine-readable from the ground up. It required everyone to agree on ontologies, use new formats, and essentially rewrite how they publish content. The incentive structure was broken: massive effort, diffuse benefit. WebMCP is different in three concrete ways: **1. It reuses existing code.** The spec is explicit: *"Any task that a user can accomplish through a page's UI can be made into a tool by re-using much of the page's existing JavaScript code."* You're wrapping functions you already have, not building a parallel API. Here's the Imperative API registering an existing function: ```javascript // You already have this async function searchProducts(query, category) { const results = await fetch(`/api/search?q=${query}&cat=${category}`); return results.json(); } // WebMCP just wraps it navigator.modelContext.registerTool({ name: "searchProducts", description: "Search products by keyword and optional category", inputSchema: { type: "object", properties: { query: { type: "string", description: "Search keyword" }, category: { type: "string", description: "Product category filter" } }, required: ["query"] }, annotations: { readOnlyHint: true }, callback: searchProducts // ← the function you already had }); ``` **2. Google will incentivize it.** They did it with mobile-responsive design (mobile-first indexing), they did it with page speed (Core Web Vitals), they did it with AMP (preferential placement). WebMCP readiness is almost certainly going to factor into search rankings for agentic queries. If your competitor's site lets agents complete tasks and yours doesn't, guess who gets recommended. **3. The AI agent market is exploding now, not in 2008.** Semantic Web asked people to prepare for a machine-readable future that didn't exist yet. WebMCP is asking people to prepare for AI agents that are already shipping in production — in ChatGPT, Claude, Gemini, and every browser. ## Practical Guide: What to Implement, In What Order Stop thinking "either/or." Here's the implementation order that gets you the most coverage fastest: ### Level 1: Accessibility Foundation (Do This Regardless) - Semantic HTML (`

`, `