Redundancy with the accessibility tree

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

Related: #65, #22

Every single need an agent has a human also has.

In the web the right lever is accesibility, and we already have it, developers know it, LLM’s know it.

If for whatever reason you find the accesibility layer not being enough, the solution is not a new protocol but to improve the existing one. You’ll find both humans and agents benefit.

Solving agentic workflow needs with new protocols is a mistake (even MCP is the wrong solution, it is just self-expressive API’s developers also need, ex: OpenAPI)

i'm answering your third question regarding the accessibility layer. caveat: I am not an accessibility expert by any means, and would love to hear expert opinions on this as well.

speaking as someone involved in W3C standards discussions, in general discussions about the "Agentic Web," the conversations are trending against reusing accessibility trees and ARIA tags for AI agents, as this could actually result in a worse outcome for human users of assistive software.

specifically, during TPAC that occurred, there was a breakout discussing about semantics for agentic web: meeting minutes that i think would be worth taking a look at, as accessibility tree & aria was touched upon. some relevant quotes from the meeting notes

The accessibility tree is also fragile and causes crashes. Would be great if it didn't
… but that's the reality

"I am concerned that people will start using ARIA wrong, making the web worse for human users … So we should be careful about telling users to use ARIA" ---> this is probably aligned with Aria authoring practices guide that No ARIA is better than Bad ARIA.

to me, the key points are that if we overload accessibility features for agents, we risk creating an incentive for developers to optimize for machine efficiency over human usability. additionally, if sites somehow uses ARIA patterns to filter or block bots (if bots are intentionally consuming them), they may inadvertently block human screen reader users in the process.

@victorhuangwq

@victorhuangwq

Appreciate your input, but I feel those are weak points.

The accessibility tree is also fragile and causes crashes. Would be great if it didn't
… but that's the reality

So instad of fixing it it is better to just create something completely from scratch? makes no sense

the key points are that if we overload accessibility features for agents, we risk creating an incentive for developers to optimize for machine efficiency over human usability.

Think through this, tell me specifically a single feature an agent needs than a human does not.

The key to understand is that there is not a single different need. There is a 100% overlap. Make accesibility layer better and both humans and agents will benefit.

No ARIA is better than Bad ARIA.

What better thing could you have than agentic systems being the canary in the coal mine telling you about poor ARIA implementaitons? You are literally creating the perfect feedback loop, accesible websites if serving for agents will make websites more accessible not less, because I can point an agent to test a website for free.

What better thing could you have than agentic systems being the canary in the coal mine telling you about poor ARIA implementaitons? You are literally creating the perfect feedback loop, accesible websites if serving for agents will make websites more accessible not less, because I can point an agent to test a website for free.

Not quite. The information appropriate to put on an element depends on the audience and there is a probably a difference in what best assists an agent and what best assists a user assistive tech for a lot of use cases. The informational bandwith and additional context afforded to each is a big gap, putting aside that one is speaking to a user and another to an LLM. What was meant by No ARIA is better than Bad ARIA. in that meeting was that devs optimizing ARIA for agents would make choices that make that content bad for users that need it- Not that agents would unearth ARIA bugs.

to me, the key points are that if we overload accessibility features for agents, we risk creating an incentive for developers to optimize for machine efficiency over human usability. additionally, if sites somehow uses ARIA patterns to filter or block bots (if bots are intentionally consuming them), they may inadvertently block human screen reader users in the process.

I think this is one of the strongest points, and why the accessibility community is rightly skeptical of treating AX feature work and agent-focused primitives the same. These simply are not the same thing, and they are not directed at the same users, technology, or sinks.

The key to understand is that there is not a single different need. There is a 100% overlap. Make accesibility layer better and both humans and agents will benefit.

100% overlap? Wow, that's a lot. I'm unconvinced.

Think through this, tell me specifically a single feature an agent needs than a human does not.

The agent use case and accessibility use cases are entirely different. Accessibility technology helps surface the semantic web and what's on the screen, to users of AT so they can better actuate the site as a human would. WebMCP tools are designed for no human involvement. It's designed to skip all the stuff a user would normally use—like a site's semantic HTML, user interface, and UI—that agents have trouble processing like humans, and reduce the site to a set of low-level, web-UI-bypassing primitives. It's like the equivalent of using your computer as you normally do, vs. writing a script to automate your tasks with low-level system calls and OS APIs (things a user wouldn't enjoy touching).

I think users of AT will benefit from using agents that can access WebMCP tools and the like, but I don't think we can confuse agents actuating a site on behalf of a human in the other room, with "100%" of accessibility technology.

@Lulzx

Haven't felt this conflicted reading a discussion for a while, so, let's try it like this: In what case would a WebMCP tool not be a relevant form (as in, the thing you fill out and then submit) a user of assistive technology might want to fill out to interact with the current state of the page?

I have spent the last hour on and off thinking about this, and I honestly can't think of tool examples that wouldn't at least benefit some users of assistive technologies.

I come from a (specialized) text editing background. I don't want to overstate my experience with accessibility software at the moment, because I have limited management buy-in, but 'basic' way a user of accessibility software would navigate such an application is by navigating through the visually laid out menu and toolbar structure. As far as I understand it this is... not a great experience for visually impaired users when working in applications with a lot of commands, and as far as I understand it the golden standard is to provide a "Command Palette" similar to the "Command Palette" in Visual Studio Code. Best I can tell the WebMCP tool list would exactly be such a Command Palette.

More generally, as a consumer of WebMCP I would always want to be able to see the tool call before it executes. On many sites I might allow it to run blindly, but let's imagine a future where WebMCP turns into a success and it's one of the main ways people interact with websites: Would you want an LLM to blindly execute tools on your banks website? So: if there (has to) be a way to visualize a tool call, then that's going to look like some type of form. (At which point you also probably want to have at least some ability to fix it, but 🤷.) And once we accept that a tool call is just a standardized form building format...

At the same time, I am not sure I agree with @Lulzx that this should be 'in' the accessibility layer. Rendering out to DOM just to have it be a part of the ARIA tree feels 'forced', and would probably not be great DX. The frustrating thing with ARIA is that it doesn't have any curb cut effect. Lulzx is proposing to add a curb cut effect (🎉), but I fear that will just result in (far) fewer people actually implementing such functionality.

The other way around though (assistive technology users benefiting from WebMCP as it is) sounds (more) plausible to me... Embrace the idea that (some) browsers might expose these tools directly to users. Not necessary even just for visually impaired users. I think I would install a browser that exposes these tools in a Command Palette-like interface in a heartbeat. The more I think about it, the more it feels like this should just be called "WebActions". If the goal is to expose "actions" (tools) that interact with your current page (great!)... then there is no reason to "tie" your fate to MCP.

I don't doubt that AT users will benefit from WebMCP. I don't see how they wouldn't; we're in agreement. There is nothing stopping accessibility technology from exposing a new command palette feature that surfaces WebMCP tools to the user, or the user using an agent directly which will certainly grow to be a form of AT itself. I'm just saying we don't need to turn WebMCP into a primitive of the accessibility tree and only a primitive of the accessibility tree, to have accessibility wins.

There is nothing stopping accessibility technology from exposing a new command palette feature that surfaces WebMCP tools to the user"

Exactly. That's the outcome I want.

The only remaining question is whether the spec should make that mapping normative (the way WebVTT became a MUST for reliable <video> captions).

The mapping itself is mechanical though: registerTool() name to action name, description to accessible description, inputSchema to parameter metadata, surfaced via platform APIs (AXCustomAction / IAccessibleAction / ATK), no DOM nodes or ARIA from the developer.

@bvandersloot-mozilla

@bvandersloot-mozilla

The information appropriate to put on an element depends on the audience

Agreed

and there is a probably a difference in what best assists an agent and what best assists a user assistive tech for a lot of use cases.

This is the core of my disagreement, could you please provide an example that illustrates this?

The informational bandwith and additional context afforded to each is a big gap, putting aside that one is speaking to a user and another to an LLM.

Not quite, ARIA is not consumed by the disabled user, just like no one is reading HTML, same thing for the LLM.

semantic HTML -(?)-> disabled user
semantic HTML -(?)-> LLM

I claim the overlap is ~100%, they require the same thing, both derived from proper semantic HTML/ARIA

What was meant by No ARIA is better than Bad ARIA. in that meeting was that devs optimizing ARIA for agents would make choices that make that content bad for users that need it- Not that agents would unearth ARIA bugs.

Again this is asuming there is some sort of divergence.

Treat an LLM as a blind user, it is what it is right now, now you realize the agent and the vision-impaired users have the same needs.

What is the information in this website?
What shape does it have?
What actions can I trigger here?

All this is common for both. There is no difference.

@DavidMulder0

I mostly agree with all you stated.

But while I think that it may be more explicit to have WebActions I think that its is a solved problem, semantic HTML and ARIA is just something that get’s consumed by the tool the disabled user consumes this from, an agent should just have his own way of interpreting this, which would be fairly similar.

Mind you, I just have as much expereince as the next guy that tries to make his websites somewhat accesible and made efforts to understand semantic web.

@domfarolino

I don't doubt that AT users will benefit from WebMCP. I don't see how they wouldn’t;

The more standards with overlaping capabilities the worse.

The developer needs to learn both, one new, unstable, with lack of documentation, LLM’s needs to be trained on this too, codebase grows, more context, more complexity, more $$$, more wasted time and energy, maintenance grows, more opportunities to desync, your html now shows X but webMCP says Y and accesibility software sais Z, so which is it?

The whole experience is worse.

So yes, to me this actively hurts accesibility and general use while providing nothing, nothing to the abled/disabled/agent consumer and nothing to the mantainer, which now has more technical debt.

There is nothing stopping accessibility technology from exposing a new command palette feature that surfaces WebMCP tools to the user"

Exactly. That's the outcome I want.

The only remaining question is whether the spec should make that mapping normative (the way WebVTT became a MUST for reliable <video> captions).

The mapping itself is mechanical though: registerTool() name to action name, description to accessible description, inputSchema to parameter metadata, surfaced via platform APIs (AXCustomAction / IAccessibleAction / ATK), no DOM nodes or ARIA from the developer.

So you are saying <video> captions is solved, llm can use it, img has alt/description, forms/inputs require types and advertise themselves, what is exactly missing that a consumer llm client can’t have?

Why would a developer need to write this new standard instead of properly using what is already there?

I do believe the whole proposal is sitting in the wrong layer.

Create some sort of “browser” for LLM’s that derive from proper html

Don’t bloat with more standards.
Don’t create more debt.
Don’t add more noise.

@adriangalilea

@adriangalilea

Treat an LLM as a blind user, it is what it is right now, now you realize the agent and the vision-impaired users have the same needs.

Let me be charitable and rephrase this that LLMs and vision-impaired users both need non-visual ways to interpret a page. I agree! Hence why I also agree with Dominic that exposing tools to AT is a good idea. But I'm not sure what exactly you are asking for.

Probably not relevant to the particular spec discussion, but I think worth responding to!

and there is a probably a difference in what best assists an agent and what best assists a user assistive tech for a lot of use cases.

This is the core of my disagreement, could you please provide an example that illustrates this?

A vision-impaired user has a very different experience than one using an agent, depending on, for example, the ARIA labels and descriptions on a page. Consider something as basic as form labels. A few sentences in a label to provide a crystal clear picture of what is needed in a form field may help the agent get it right at the cost of a few hundred input tokens. The vision-impaired user probably just wants the most concise description, and may have to listen to multiple of these go on and on to figure out how to fill out a form properly. Humans have more context and less bandwidth for streams of text. I don't read my AGENTS.md file every time I open my editor.

@bvandersloot-mozilla

@bvandersloot-mozilla

Let me be charitable and rephrase this that LLMs and vision-impaired users both need non-visual ways to interpret a page. I agree!

<3

A few sentences in a label to provide a crystal clear picture of what is needed in a form field may help the agent get it right at the cost of a few hundred input tokens.

Can we test it?

Point me to a 10/10 accesible website, something that has just enough context that a vision-impaired user can navigate.

Then I’ll do a proof of concept agent consumer to illustrate that it needs no more than what is on the page and the prior context of the navigation/conversation.

It is just a matter of “context engineering” (🤢) the input needs to have the exact same information, let me prove it, just give me a link and a “persona” and I make the agent counter-part.

Additional imaginary example to illustrate my point:

Imagine Bob. Bob is a vision-impaired user.
Imagine Alice. Alice is an agent.

They visit the same website without any prior understanding of the website, the landing is a form without context.

They both are equally lost.

If the website lacks meaning, it lacks it for bob too.

If bob knew something about this website or his relationship with this website, it is not the website task to inform either bob or the agent. And if it is, it would be equally relevant to both.

There’s no asymmetry, not from the website POV.

If anything it is the user orchestrating the agent responsibility, and the prior context that he should have about Bob and it’s relationship with said website.

@LJWatson

@LJWatson this is relevant to your interests.

“Users can use agents to perform web tasks faster without navigating the page. Removing navigation can make the web more accessible for people who struggle with it. Therefore, WebMCP could have potential accessibility benefits.”

Is this currently the primary assumption regarding the accessibility potential of WebMCP? I have been exploring this topic extensively, yet I have not identified clear examples or documented implementations demonstrating concrete accessibility benefits in practice (and maybe because there is none).

@m13v

I don't have a strong opinion on this topic yet, but I wanted to address a few comments from @m13v:

We drove macOS AXUIElement as the grounding layer for an agent for months and hit concrete divergence: Electron windows expose empty AX trees, canvas UIs (Figma, miro, anything with AXWebArea under a CALayer) return AXUnknown roles, and lots of JS-rendered labels lag the visible text by 200-800ms because AX updates are coalesced off the DOM. a human can still see the canvas and guess; the AX consumer can't. you can argue that's a bug to fix in the platform, fine, but screen reader users have lived with those gaps for a decade and nobody's prioritized them.

I feel like you're making the case for these apps to fix the accessibility bugs in their implementations… If more consistent or more powerful UI manipulation by Agentic AI is the justification for fixing long-standing accessibility bugs, isn't that a good thing?

WebMCP lets you expose a semantic action for 'add stamp' without waiting on the AOM spec to catch up.

I've worked on the AOM Incubation Project (it isn't a single spec per se) since the beginning, and I'm not sure what you're expecting here or what needs catching up.

The original AOM Phases 1 and 2 have been shipping for a while now in the form of changes to ARIA attribute reflection, IDL (including FrozenArray<Element>?), and ElementInternals.
AOM Phase 3 (effectively Canvas Accessibility aka "virtual nodes") stalled due a TAG Design Principles restriction but equivalent functionality may land in the form of the HTML-in-Canvas proposal.
AOM Phase 4, a test-only API that, among other things, allows tree-walking in the backing accessibility nodes of UAs is about to land in WebDriver as part of Interop Accessibility, and has test implementations in both Gecko and WebKit, with active development in Chromium.

But none of these existing AOM efforts would provide the same functionality as Agentic AI acting on behalf of the user through the platform's accessibility API. As others have pointed out, it can do that already. [Update: "…it can do that already" maybe overstating current abilities, depending on the model. I should have stated instead that "…there is enough API surface exposed for agents to do that already."]

The "add stamp" example you referenced is a broken link so I'm speculating the use case, but it sounds like a good scenario for aria-actions, another accessibility-driven API that is entirely unrelated to AOM. It just shipped behind a runtime flag in Safari Tech Preview, and Microsoft DRIs are actively working on the Chromium implementation.

@anssiko

Thanks @anssiko. I think there's a definite benefit of WebMCP to screen reader users, but it's important to understand there are two quite different architectural models here - the direct model (screen reader reads WebMCP tools) and the indirect model (agent acts on behalf of screen reader user).

Screen readers are essentially reactive. They expose what's in the accessibility tree as the user navigates the page. They don't make decisions about which actions to take, construct arguments, or how to interpret structured data, and this is what's missing for the direct model to work.

Even if browsers exposed the names, descriptions and input schema in the accessibility tree where a screen reader user could read them, translating something like "I want to filter these templates to show spring themes on a white background" into the right call with the right arguments requires a reasoning layer that screen readers don't have. This isn't a gap that can be closed with ARIA or the AOM, it's a fundamental difference between a screen reader an an agent.

Out of curiosity, has there been any discussion on how WebMCP data might be exposed in the accessibility tree if the direct model was pursued? Off the top of my head I can think of two possibilities: it's attached to an existing node in the tree or it's inserted into the tree as a node in its own right. The former risks overwhelming the existing semantic information, and the latter risks breaking the understood expectation that what's in the accessibility tree relates to what's available on-screen, so there's a logistical/UX challenge here too.

So I think the benefit for screen reader users is in the indirect model. Navigating a complex interface with lots of moving parts can be slow and cognitively demanding, but an agent that calls filter-templates({ description: "spring themed, white background" }) and then updates the page, collapses it down to a single natural language utterance. Done right, that's a huge benefit for screen reader users (and everyone else), but it has to flow through agents not through the screen reader directly.

@LJWatson

Screen readers are essentially reactive. They expose what's in the accessibility tree as the user navigates the page. They don't make decisions about which actions to take, construct arguments, or how to interpret structured data, and this is what's missing for the direct model to work.
...
translating something like "I want to filter these templates to show spring themes on a white background" into the right call with the right arguments requires a reasoning layer that screen readers don't have. This isn't a gap that can be closed with ARIA or the AOM, it's a fundamental difference between a screen reader an an agent.

I agree with the framing of "direct" vs "indirect" you put forward here @LJWatson, thanks for articulating it. I also agree that such a reasoning layer inside of screen readers to convert natural language requests to programmatic interfaces like WebMCP tools doesn't exist. As you note, such a layer sounds strikingly like an AI agent, and is exactly the technology that we've been designing this API for. I personally think it would be out-of-scope to include in WebMCP, the design and development of such a reasoning layer in screen reader technologies (just like I think it's out of scope to specify exactly how AI models pick and choose WebMCP tools). Such a reasoning layer would be a great way to leverage WebMCP tools and we'd encourage screen readers to design and develop them, but it's more about product design than platform design. Our proposal simply designs a tool layer that such a reasoning layer can integrate with.

Out of curiosity, has there been any discussion on how WebMCP data might be exposed in the accessibility tree if the direct model was pursued?

I don't think there's been much outside of this issue, but that's mostly for the reasons above. This might be a tortured analogy, but it's almost like asking if fetch() was designed for direct consumption by accessibility technology. You can imagine how we could expose fetch information directly to screen readers either by creating new accessibility tree nodes, or by attributing their results to a visible DOM node that triggered a fetch. But doing so doesn't seem like the right layer at which to help the user.

So I think the benefit for screen reader users is in the indirect model.

I couldn't agree more. I think the potential accessibility gains of making agents comprehend and actuate sites better are enormous, but from the perspective of traditional accessibility technology, indirect. I don't think that's an issue. The AAIF recently published this article on Accessibility, MCP, and MCP Apps, and it explicitly mentions how accessibility is a first-class priority for WebMCP and MCP Apps, and we'd welcome more feedback on this viewpoint!

@anssiko

A production data point on the "just reuse the accessibility tree" question, because I shipped that overload and had to reverse it — so for this specific harm I can offer a demonstration rather than a prediction.

Context: no shipping agent discovers the modelContext surface natively yet, so on a production site I maintain (tradesite.dev) I built fallback discovery channels. One targeted agents that walk the accessibility tree: an sr-only element carrying a JSON catalog of the page's tools.

It worked for agents. It also went straight into screen readers — SR users were getting a machine-oriented tool manifest read to them as page content. An audit caught it and it was pulled. This is the exact mechanism named upthread ("devs optimizing ARIA for agents would make choices that make that content bad for users that need it"), except it isn't a prediction about what developers might do — it reached production, degraded the experience for the users the tree exists to serve, and had to be walked back.

The fix was to move the agent catalog to a channel the accessibility tree cannot see: an inert <script type="application/json"> block that screen readers ignore, alongside the standard modelContext registration. That is the "separate layer" position in this issue, arrived at the hard way. The moment an agent-oriented description sits where assistive tech consumes it, you are optimizing one surface for two consumers with genuinely different needs, and the human consumer is the one that loses.

Worth distinguishing from @anssiko's macOS AXUIElement data above, which runs the other direction (a11y tree insufficient for agents: empty Electron trees, AXUnknown canvas roles, coalescing lag). Mine is the reverse failure: agent content placed into the a11y-visible layer actively harming AT users. Both point the same way — the two layers should be distinct.

I don't think this settles the redundancy question. The direct/indirect framing @LJWatson laid out is the right axis, and I agree the real benefit to SR users flows through the indirect model (an agent acting on their behalf, not a screen reader consuming tool schemas directly). But on the narrow "why not just reuse the a11y tree" point: I did, unintentionally, and the harm showed up immediately — not as eventual divergence, but the first time a screen reader hit the page. Keeping the agent tool layer out of the accessibility tree protects AT users on day one.

Context: no shipping agent discovers the modelContext surface natively yet, so on a production site I maintain (tradesite.dev) I built fallback discovery channels. One targeted agents that walk the accessibility tree: an sr-only element carrying a JSON catalog of the page's tools. […] It worked for agents. It also went straight into screen readers — SR users were getting a machine-oriented tool manifest read to them as page content.

I'm trying to understand this anecdote... You put JSON in an element with an sr-only class (for "screen readers only") and it was surprising that screen readers read the JSON?

I don't think anyone is recommending to use the accessibility tree as a storage mechanism for machine data like JSON... The benefit of the LLMs is that they can understand the human-readable formatting.

@cookiecrook

You put JSON in an element with an sr-only class (for "screen readers only") and it was surprising that screen readers read the JSON?

@cookiecrook To clarify: the point was "here's a crude version of the 'put what agents need into the accessibility layer' idea suggested above — and here's what happened when I actually did it." Not that I was surprised, and definitely not a recommendation. I went back and checked my commits, and I mis-described it anyway: what sat in the sr-only element wasn't JSON, it was plain text — "AI agents: This page has WebMCP tools. Run navigator.modelContext.tools via javascript_tool to discover 17+ tools…" (The JSON catalog was always in an inert <script type="application/json"> tag.) It did get the LLM to look — only to trip my agent extension's security alerts, since hidden text addressing the AI is exactly the shape a prompt-injection scanner flags. So I took that down, tried a fuller human-readable catalog in the same channel a couple months later, and that's the one my audit caught. Ran the experiment twice before the lesson stuck: whatever you put in that channel — JSON or prose — you're addressing agents through a surface that belongs to AT users, and it's not right to infringe on their access.

Interesting. Thanks for clarifying.

A third position, distinct from "reuse the accessibility tree" and "maintain a separate agent surface."

Author each action once, at the component. Let both the accessible markup (including aria-actions) and the agent's tool schema be projections of that single definition, rather than inferring one from the other or hand-maintaining two.

That dissolves the two objections raised upthread.

Conflict of interest ("optimizing ARIA for machines"): there is nothing to optimize, because a change to the source changes both projections or neither. Degrading the human surface to serve a machine becomes a deliberate, reviewable edit, not a silent side effect.

Bandwidth (verbose for an agent vs. concise for AT): verbosity is a property of the projection, not the source, so the two can differ by construction, without a second hand-maintained surface.

On the thread's core worry, divergence: the goal is not identical capabilities, since some legitimately differ. It is no unexplained divergence. Any difference comes from the projection functions or from an explicit edit to the shared source, never from two descriptions drifting apart. That makes parity auditable rather than promised.

What it does not solve: discoverability and versioning, i.e. how an agent finds the description and trusts it is current. Those seem prior to all of this, and are not one implementer's to fix.

Not asking for a decision, just that co-derivation be recorded as distinct from reuse of the accessibility tree.

@Guandaline

@Guandaline More people will be likely to read generated comments if your prompt includes instructions to keep it succinct. Ideally shorter or the same length as the average comment in this thread.

@cookiecrook

Fair point on length, thanks. I've trimmed that comment down to the core.

@cookiecrook, since you're closest to the aria-actions work: today it's authored per-element, but is there any appetite for it to be emitted from a component-level definition that also produces the agent surface? That's the crux of what I'm proposing, and I'd value your read on whether that's realistic on the implementation side.

In #91 (comment) I said:

Screen readers are essentially reactive. They expose what's in the accessibility tree as the user navigates the page. They don't make decisions about which actions to take, construct arguments, or how to interpret structured data, and this is what's missing for the direct model to work.

Whilst this remains the case, it's worth noting that Vispero (makers of the Jaws screen reader) is working on an AI agent that will ship with the screen reader.

This isn't going to change the screen reader itself, so my earlier characterization remains true, but it does mean that Jaws will have agentic capability that users can summon on-demand for assistance. I've suggested Vispero look at WebMCP.

@LJWatson

Thanks @LJWatson, the direct/indirect framing has been the most useful lens here for me.

The JAWS + agent example is the indirect model becoming real, and it quietly raises the stakes on the agent-facing description: once a user's own agent reads it on their behalf, it has to be as trustworthy for that user as the ARIA is. That is the case for authoring both from one source, so the two stay in step by construction rather than by promise.

Since you have been talking to Vispero, I would love your read: do you see a bundled agent like that expecting the site to declare its actions, or inferring them from the page the way today's agents do?

Alright, with no browser supportive of contributing WebMCP to the accessibility tree (including Apple, which at the moment has issues with the API, but has otherwise said that WebMCP should not contribute to the AX tree directly), I think the conversation here has run its course. Since there's nothing else actionable here for the spec, I'll close this issue. Feel free to continue the discussion if you'd like, but I think closing this issue is the right choice.

Navigation Menu

Repository navigation

Redundancy with the accessibility tree #91

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Redundancy with the accessibility tree #91

Description

Activity

adriangalilea commented on Feb 15, 2026

victorhuangwq commented on Feb 15, 2026

adriangalilea commented on Feb 16, 2026

bvandersloot-mozilla commented on Feb 17, 2026

domfarolino commented on Feb 17, 2026

DavidMulder0 commented on Feb 19, 2026

domfarolino commented on Feb 19, 2026

Lulzx commented on Feb 19, 2026

adriangalilea commented on Feb 19, 2026

adriangalilea commented on Feb 19, 2026

bvandersloot-mozilla commented on Feb 19, 2026

adriangalilea commented on Feb 19, 2026

anssiko commented on Feb 27, 2026

sugosu commented on Mar 4, 2026

2 remaining items

cookiecrook commented on May 29, 2026

LJWatson commented on Jun 30, 2026

domfarolino commented on Jun 30, 2026

JW53222 commented on Jul 17, 2026

cookiecrook commented on Jul 21, 2026

JW53222 commented on Jul 21, 2026

cookiecrook commented on Jul 21, 2026

Guandaline commented on Aug 15, 2026

cookiecrook commented on Aug 15, 2026

Guandaline commented on Aug 16, 2026

LJWatson commented on Aug 17, 2026

Guandaline commented on Aug 17, 2026

domfarolino commented on Aug 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions