There’s a proposal circulating in web standards circles called WebMCP. The idea is straightforward: give AI agents richer, more actionable access to web content so they can interact with sites more effectively on a user’s behalf.
The problem is how it’s being built. WebMCP creates a separate layer of semantics specifically for AI agents. Screen reader users, keyboard users, and everyone else relying on the shared web platform get the same experience they had before. AI gets a better web. Everyone else stays put.
Jason Grigsby at Cloud Four wrote about this recently, and he captured the issue well: “Proposed changes to the web platform to support AI should also support users and assistive technology whenever possible.”
The Safari team pushed back on WebMCP with exactly the right instinct. In their opposition, they wrote: “When a site’s actions are hard for an agent to use, that is a gap in the page’s own semantics, and the fix, in our opinion, is to close it in the platform’s shared layers (HTML and ARIA), where the user, assistive technology, and agents all benefit.”
This pattern should sound familiar to anyone who works in accessibility. We’ve seen it before. ARIA bolted on as a repair mechanism instead of proper semantic HTML. Separate accessibility overlays instead of accessible foundations. Skip links added as an afterthought instead of a logical page structure. The lesson keeps repeating: separate solutions for specific audiences create two-tier experiences. The shared platform should always come first.
The argument here isn’t anti-AI. It’s pro-good-web. If AI agents need richer semantics to navigate a site effectively, those semantics should live in HTML and ARIA, where screen reader users and keyboard users benefit too. Building a better web for AI should mean building a better web for everyone.
When we build for everyone, everyone benefits. That’s not an accessibility argument. It’s just good web development.
Don’t Miss Out
Get practical accessibility tips in your inbox every week.