Accessibility

[idosal]

MCP Apps are rendered in a sandboxed iframe. Accessibility depends heavily on both the host and the app.

We should validate that the spec provides the hooks and constraints needed for strong accessibility (keyboard/focus management, screen reader support, labeling, theming/contrast, zoom/magnification behavior) and that apps must meet these expectations.

[phillamb168]

First, thanks for creating the issue. I'm working with the American Council of the Blind on some MCP integrations and in my discussions with them, they are VERY excited about both the current state as well as potential future state for AI generally. I've got a meeting with them tomorrow morning and I'm going to be asking about getting a pool of folks together who might be able to help with real-world a11y testing, and the people on their end I've worked with in the past on similar tasks have been quite thorough.

Anyway - quick first pass on this issue: I think we should separate what the spec can standardize from what each host must implement, and I'd like some input on the below breakdown:

Where I think we’re at now:

• The spec already gives us good plumbing for host < -- > app coordination (sandboxing, host context, theming tokens, display mode, sizing, safe-area insets, context change notifications).
• That plumbing helps accessibility, but it doesn’t yet define clear accessibility expectations.
• In particular, keyboard/focus behavior across host + iframe boundaries, screen reader semantics/labeling expectations, and zoom/reflow behavior are not explicitly spelled out as requirements.

Things I think we need to clarify next:

• Which accessibility behaviors should be required by the spec (host-agnostic contract)?
• Which behaviors are host-owned implementation details (Claude/ChatGPT/etc. UI patterns)?
• Which behaviors are app-owned (semantic HTML, focus-visible, labels, announcements, etc.)?
• What should be tested for conformance vs recommended as best practice?

Proposed path forward (before drafting spec text):

1. Create a host/app/spec responsibility matrix for key accessibility areas (keyboard/focus, SR support, labeling, contrast/theming, zoom/magnification).
2. Turn that matrix into a practical test checklist we can run across basic-host + at least one production host.
3. Use those findings to decide:
   • doc-only guidance,
   • normative spec clarifications,
   • or protocol additions (if any gaps can’t be solved with current hooks).
4. Bring in external SR/AT validation (ACB resources (see above) and others) once the checklist is stable, so we test against real workflows, not just assumptions.

What do you think? I can also put together the initial responsibility matrix/checklist in a follow-up.

[willsutton]

Hi @idosal — happy to see this issue. I’m head of innovation at AbilityNet (UK accessibility charity).

The host/app split in MCP Apps is a genuinely interesting accessibility surface — the rendering layer being separable from the source service creates opportunities (host can enforce semantic structure, focus patterns, AT conventions consistently) but also risks (status messages crossing the iframe boundary, focus management at sandbox edges, host conformance silence in the current spec).

I’m planning to spend some time auditing the current draft and the example apps against WCAG 2.2 AA over the coming month, and will follow up here with concrete findings.

A couple of questions in the meantime that would help shape that:

1. Is the intent for accessibility to live as part of the core MCP Apps spec, or as a profile/extension on top?
2. Are there host implementations you’d specifically like the audit to cover beyond basic-host?
3. Has the WG discussed accessibility informally on Discord that I should catch up on before commenting further?

[phillamb168]

Hi @willsutton, I was just on a call with Jeff Bishop at ACB when I saw your comment come in, he mentioned he knows you. Your perspective on the host/app accessibility surface (and the planned WCAG 2.2 AA audit of the draft + example apps) is going to be incredibly valuable. Thank you.

Quick answers to your questions, from my perspective/opinion:

1. Core spec vs. profile/extension: My own take (and what I proposed a bit earlier in the thread) is that the host/app contract around accessibility should live in the core MCP Apps spec wherever we can make it host-agnostic and enforceable (focus management across iframe boundaries, status-message announcements, theming/contrast guarantees, safe-area/zoom behavior, etc.). Anything that ends up being host-specific UI patterns or deeper guidance could be non-normative appendices or a separate profile. Definitely something the WG should discuss explicitly.

2. Hosts to cover: basic-host is the highest-priority reference implementation. Any production hosts you’re able to test (Claude Desktop, ChatGPT, etc.) would be excellent additional data points.

3. Discord: There’s an active thread in the #mcp-apps-wg server called “a11y for Apps” (started ~April 4 2026). If you drop me your Discord handle I’ll add you immediately, or you can scroll back and jump in.

On the ACB side: As I said earlier, I just got off the phone with my contacts at the American Council of the Blind. Our call was mostly about broader AI adoption, but in an earlier conversation Dan (ACB president) said something that’s stuck with me and I think gives this issue real urgency: “If you get it right out of the gate we’re not a generation behind again.” They’re very excited and have already offered to pull together a pool of technical users for real-world testing once we have something stable to run against.

I’ll post an initial draft of the host/app/spec responsibility matrix and practical test checklist I mentioned earlier as a strawman/starting point for discussion. I’d love to incorporate your audit findings and coordinate with both AbilityNet and ACB folks so we’re testing against real workflows (screen readers, keyboard-only, magnification, etc.).

Let me know how you’d like to sync up and of course quite happy to facilitate any intros (sounds like you may not need them XD )

[phillamb168]

Initial Draft – MCP Apps Accessibility Responsibility Matrix
(Strawman / starting point based on the earlier discussion.)

Accessibility Area	Spec (normative)	Host Responsibilities	App Responsibilities	Testing / Notes
Keyboard / Focus Management	Define focus delegation, trapping, and boundary behavior across iframe	Consistent focus styles, handle entry/exit from iframe, respect system focus preferences	Logical tab order, focus-visible, proper tabindex inside the iframe	WCAG 2.4.3, 2.4.7; test keyboard-only
Screen Reader Support & Announcements	Requirements for live regions / status messages to cross boundary	Expose proper roles/ARIA to AT; handle iframe semantics	Semantic HTML, ARIA labels/roles, role=alert, aria-live etc.	WCAG 4.1.3; test with NVDA + VoiceOver
Labeling & Semantic Structure	Expectations for accessible names/descriptions	—	Proper <label>, aria-labelledby, aria-describedby etc.	WCAG 4.1.2
Theming / Contrast / High-Contrast	Require host theming tokens (light/dark/high-contrast)	Supply tokens, respect system preferences	Use tokens, ensure minimum contrast ratios	WCAG 1.4.3 / 1.4.6
Zoom / Reflow / Magnification	Requirements for reflow at 200% / 400% zoom	Support viewport resizing and safe-area insets	Responsive layout that reflows without loss of content/function	WCAG 1.4.4, 1.4.10
Status Messages / Dynamic Updates	Protocol for host to surface app announcements	Route announcements across iframe boundary	Use aria-live, role=status etc.	WCAG 4.1.3

[willsutton]

@phillamb168 Thanks for the warm welcome. Discord handle is suttzz it would be great to be added to the a11y for Apps thread. I’ll read back through it before commenting.

I agree on the core-spec / non-normative-appendix split. Host-agnostic and enforceable in core, host-specific patterns as appendices or a profile, feels right.

Quick thought on the matrix as additions for WG discussion:

Cognitive accessibility as its own row. Probably the strongest opportunity the host/app split creates — the host can offer plain-language alternatives, simplification, and mode-shifting on demand, none of which retrofit that well onto traditional sites.

On the audit: spec and basic-host feel like good starting points. I’ll post findings in the Discord thread first so the WG can shape what comes back here.

AbilityNet also has an existing diverse user research capability — happy to explore coordinating with ACB when the time is right, the two together would be a strong evidence base.

[liady]

On that topic - a post authored by @phillamb168 for the AAIF about the current state of agentic accessibility, including View Tools / WebMCP, etc: https://aaif.io/blog/native-speakers-why-ais-most-powerful-users-are-blind/