The accessibility tree already provides a machine-readable representation of a page's action space: labels, roles, states, expected inputs, validation errors, element relationships. Assistive technologies (screen readers, voice control, switch access) use this to perform actions a page supports.
An AI agent can use the same interface. No additional protocol is needed.
If a capability is missing from the accessibility tree for agents, it is also missing for assistive technology users. The fix should be in the accessibility layer, not in a parallel system. This serves both use cases with one implementation.
WebMCP introduces a second description of the page alongside the accessibility tree. These will diverge over time. The accessibility tree cannot desync because it is derived from the DOM. A separately maintained JavaScript tool registry can and will.
Structured tool schemas with typed parameters are not a UI-layer concern. This is what REST/GraphQL APIs are for. The explainer already states WebMCP is not a replacement for backend integrations.
The stamp database example (adding a stamp as a single high-level action rather than filling individual fields) is also useful for assistive technology. If this abstraction is needed, it should be added to the accessibility layer (AOM, ARIA extensions) where it benefits all consumers.
Is there a concrete use case that:
- Cannot be handled by the accessibility tree (current or with extensions)
- Is not better served by a backend API
- Would not also benefit assistive technology users if added to the accessibility layer