How the Model Context Protocol represents a convergence point between accessibility standards and AI-mediated web interaction.
The Convergence Thesis
There's a pattern emerging that most people haven't noticed yet: accessibility interfaces and AI agent interfaces are converging toward the same architectural requirements.
Both need:
- Structured data separated from visual presentation
- Programmatic discovery of capabilities
- Semantic meaning over styling
- Machine-readable interaction points
This isn't a coincidence. It's a fundamental insight about how we should be building web services.
A Brief History of Web Interfaces
| Era | Primary Interface | Machine Accessibility |
|---|---|---|
| Web 1.0 (1990s) | Semantic HTML documents | Screen readers parsed markup directly |
| Web 2.0 (2000s) | JavaScript-heavy SPAs | ARIA attributes bolted on after the fact |
| API Era (2010s) | REST/GraphQL for machines, UI for humans | Separate codepaths, duplicated logic |
| AI Era (2020s) | AI agents mediate between services and users | Need discoverable, structured interfaces |
Each transition exposed the same problem: when we build for visual presentation first, we create barriers for any consumer that isn't a human with a standard browser.
Screen reader users know this intimately. They've spent decades dealing with websites that work fine visually but are unusable when the presentation layer is stripped away.
Now AI agents face the same challenge. They can scrape HTML and try to understand it, but that's fragile, slow, and error-prone. What they actually need is exactly what accessibility advocates have been asking for all along: structured, semantic, discoverable interfaces.
The MCP Discovery Pattern
The MCP Discovery specification I've been working on addresses this by providing a standard way for websites to advertise their capabilities:
{
"mcp": {
"spec_version": "2026-01-24",
"status": "draft",
"servers": [
{
"name": "hastebin",
"description": "Text paste and sharing service",
"url": "https://haste.nixc.us/mcp",
"capabilities": ["create-paste", "retrieve-paste"]
}
]
}
}An AI agent hitting /.well-known/mcp.json can immediately understand what services are available, how to authenticate, and what capabilities each service offers.
This is the same information a well-designed accessibility API would expose: what can be done, how to do it, and what the result will be.
Accessibility and Agents: Same Requirements
Consider what a screen reader needs to make a website usable:
- Structure discovery - What elements exist? What's their hierarchy?
- Capability enumeration - What actions can be taken? Buttons, links, forms?
- Semantic labels - What does each element mean?
- State information - Is this checkbox checked? Is this section expanded?
- Interaction patterns - How do I activate this?
Now consider what an AI agent needs:
- Service discovery - What APIs exist? What's available?
- Capability enumeration - What actions can be taken? What endpoints?
- Semantic descriptions - What does each service do?
- State information - What's the current status? What data exists?
- Interaction patterns - How do I invoke this?
The parallel is striking. Both are asking the same fundamental question: "What can I do here, and how do I do it?"
The Disappearing Visual Web
Here's the speculative part: as these technologies mature, we may see the visual web become one rendering option among many rather than the primary interface.
Consider a user with severe visual impairments today. Their experience is:
- Browser downloads HTML/CSS/JS
- Browser renders to visual pixels
- Accessibility layer extracts structure back out
- Screen reader presents information aurally
That's wildly inefficient. The page was semantic, became visual, then got re-semanticized.
A more sensible architecture:
- Browser fetches structured data
- User's preferred rendering surface presents it
- No wasted visual rendering step
Now consider an AI agent helping someone book a flight:
- Agent discovers airline's MCP endpoint
- Agent queries available flights directly
- Agent presents options through whatever interface the user prefers
- User confirms, agent executes booking
The visual website never enters the picture. The airline's web interface becomes just one possible rendering of their underlying services—useful for some users, unnecessary for others.
Agentic Browsing as Assistive Technology
This reframing is powerful: AI agents are a form of assistive technology.
They assist users by:
- Navigating complex interfaces on their behalf
- Translating between systems and human intentions
- Handling repetitive tasks automatically
- Adapting information presentation to user preferences
This is exactly what traditional assistive technologies do, just at a different level of abstraction.
A screen reader assists by translating visual interfaces to audio. An AI agent assists by translating user intentions to API calls. Both are bridging the gap between how systems present themselves and how users want to interact.
Implications for Web Architecture
If we accept this convergence thesis, several architectural implications follow:
1. MCP as Accessibility Infrastructure
MCP discovery documents could evolve to serve both AI agents and assistive technologies. The same endpoint that tells Claude about your API could tell a screen reader about your application's capabilities.
2. Content-Presentation Separation at the Protocol Level
Instead of HTML as the universal format with CSS for presentation, we might see:
- Structured data as the canonical format
- Multiple rendering protocols (HTML, MCP, accessibility APIs)
- User-selected presentation layers
3. Browser Evolution
Browsers could become:
- MCP-aware, natively understanding service discovery
- Multi-modal, supporting various rendering surfaces
- Agent-integrated, with built-in AI assistance
4. Progressive Enhancement Redefined
Traditional progressive enhancement: core HTML, enhanced with CSS and JS.
Future progressive enhancement: core structured data, enhanced with visual rendering when useful, accessible through MCP when an agent is involved.
My Live Implementations
I've implemented MCP discovery on several services to explore these ideas:
Hastebin Service
haste.nixc.us provides paste functionality with MCP support:
- MCP Endpoint: haste.nixc.us/.well-known/mcp.json
- Use case: AI assistants can create/retrieve pastes programmatically
- Accessibility parallel: Same interface a specialized paste-management app could use
Markdown Renderer
md.colinknapp.com offers markdown rendering:
- MCP Server: Available for document conversion
- Use case: Agents can render markdown without scraping a web UI
- Accessibility parallel: Clean API avoids parsing complex web interfaces
This Website
colinknapp.com/.well-known/mcp.json demonstrates the discovery pattern:
- References the formal specification
- Lists available tools and services
- Provides a working example for implementers
Future Speculations
Browser-Native MCP (Near term)
Browser extensions already exist that read MCP discovery documents. Native browser support seems inevitable:
- URL bar could indicate "MCP services available"
- Browser could offer to connect user's preferred AI agent
- Developer tools could show discovered capabilities
Accessibility-First Enables Agent-First (Medium term)
Organizations that invested in accessibility will find their services naturally agent-ready:
- Semantic structure translates to API structure
- Tested interaction patterns work for agents too
- Accessibility-compliant means agent-compatible
Custom Rendering Surfaces (Long term)
Users might configure personal rendering preferences:
- "Render all commerce sites as simple product lists"
- "Present news as audio summaries"
- "Show all forms as conversational interfaces"
The underlying data would be standard; the presentation would be user-controlled.
The Visual Web as Legacy Interface (Very long term)
For certain use cases, visual web browsing might become what terminal interfaces are today: still used by some, but not the primary interaction mode for most people.
Many interactions could be entirely mediated:
- Booking systems → agent handles logistics
- Data entry → agent fills forms from user intent
- Research → agent synthesizes across sources
The visual interface remains for cases where human judgment of visual content matters, but becomes optional for transactional interactions.
Observations
- Accessibility work is agent work: Investments in accessibility now pay dividends as AI agents become prevalent.
- MCP is an accessibility standard: Viewed through this lens, MCP discovery is about making services accessible to all consumers, not just visual browsers.
- The future is multi-modal: No single interface will dominate. Services need to support visual, aural, agent-mediated, and other interaction modes.
- Structure over style: The more we can represent interactions as structured data, the more flexible our systems become.
- User control over presentation: Ultimately, users should control how they receive and interact with information, not service providers.
Conclusion
The Model Context Protocol and its discovery mechanism aren't just about AI agents talking to services. They represent a broader shift toward treating the visual web as one possible interface among many.
This shift validates decades of accessibility advocacy: the insistence that content should be separate from presentation, that interactions should be semantically meaningful, that users should control their experience.
AI agents and assistive technologies are converging on the same requirements because they face the same fundamental challenge: interacting with services designed primarily for visual human consumption.
The solution for both is the same: structured, discoverable, semantic interfaces. MCP discovery is one implementation of that solution. More will follow.
For the formal specification of MCP Discovery via Well-Known URI, see the specification document.