Accessibility tree/element(s) snapshot - exposing semantics, roles, states, ARIA,...

[BogdanCerovac]

Is your feature request related to a problem? Please describe.
I miss more functionality to extract accessibility information from DevTools with MCP. One basic thing that would be a great start is perhaps an snapshot of the accessibility tree (probably as an extension to the "text-only" snapshot or similar.

Describe the solution you'd like
Add a feature for accessibility tree snapshot of the whole page or of a single selector (CSS, XPATH) or a group of selectors (CSS, XPATH) - so that I can use MCP to extract accessibility information (semantics, ARIA and everything that can be done by manual inspection).

Describe alternatives you've considered
Not sure if there are any alternatives possible. If they are - we need to know about them - perhaps documentation with accessibility in mind would be an alternative (especially if feature is already in place).

Additional context
MCP for DevTools with accessibility in mind would help developers, designers and content providers. Perhaps also assistive technologies that can use MCP.

[OrKoN]

Note that the text snapshot is based on the a11y tree snapshot. We currently do not support selectors but you should already get the a11y tree information for the entire page. Could you clarify which specific a11y information do you miss from the snapshot?

[BogdanCerovac]

Right, thank you very much, I haven't checked the code, before, just went through the docs. Now I've checked the code and see that, yes, thanks.

In https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/src/formatters/snapshotFormatter.ts#L32 I think we can see a narrowed down list of possibilities (limited list). That probably means that with using snapshot today don't get "the whole picture" (I didn't run the code to see what happens, just guessing).

This can lead to issues when we want to improve accessibility - limiting the context (also for AI).

Perhaps we can have a "non filtered" snapshot - to get absolutely all accessibility information? Without any filtering.

Second suggestion is to be able to ask for specific elements / parts of the tree, removing the need to drill down manually (and making it possible to save on tokens if needed or if we analyze gigantic trees). But I guess that one is not so vital.

Having an unfiltered snapshot of the whole "accessibility tree" would be a great start... Supporting also elements beyond text (landmarks etc.).

[OrKoN]

@BogdanCerovac could you perhaps provide details about the use case you are after? because an alternative could be is that we offer something like lighthouse a11y audits instead of given all data to the LLM.

[BogdanCerovac]

Sure, AI audits exposing Lighthouse fails is a good start absolutely. I would expect it to be included in DevTools MCP.

My personal use case is that I can ask AI IDE for accessibility details when it makes changes and help me be more effective with debugging (I spend a lot of time in accessibility details pane when doing/debugging (advanced) ARIA widgets).

Helping my AI IDE with this info - connected to the DevTools would provide context to AI and me and make us more efficient.

I think that MCP for DevTools should do that. But as a minimum I would also appreciate Lighthouse scores, absolutely.

On the other hand we need to use Playwright / Puppeteer and other third party MCPs to get the context out of DevTools and I feel that is kind of less optimal if we can just use the DevTools for A11y directly...

[OrKoN]

Thanks for details. I think it makes sense to have this.

[OrKoN]

Although I think the current options we return in the MCP server are all of the options supported by Puppeteer https://pptr.dev/api/puppeteer.serializedaxnode (it is based on Puppeteer) so while the list is restricted I think it includes everything.

[BogdanCerovac]

Thanks, I think it will make things more transparent and effective and with more context to AI, I hope, it will be easier to fix some real barriers from code perspective.

[BogdanCerovac]

Although I think the current options we return in the MCP server are all of the options supported by Puppeteer https://pptr.dev/api/puppeteer.serializedaxnode (it is based on Puppeteer) so while the list is restricted I think it includes everything.

Will check this out later, and do a couple of tests with MCP to gather more details and get back to you, thanks.

[BogdanCerovac]

@OrKoN - Ok, did some quick testing and got some useful results, but unfortunately I am afraid that there are some semantics left out (and I would really like to get all of it all of the time).

Didn't have the time to test more, but as a very basic example - please check a website with moderate complexity and compare it's accessibility tree with the snapshot. I suppose it will not be 1:1 all of the time.

Example - I did a test on one of my test sites with different tables. No table semantics whatsoever was exposed in the snapshot, while I can simply find it in the accessibility pane;

I think that a snapshot should expose the whole accessibility tree at all times. (and Ideally I could also ask about specific elements for larger sites and to save tokens). Seems that there are some abstractions or filters preventing it and it is therefore not very reliable for testing (I would still need to check the accessibility pane and explain it to my AI agent).

I think that MCP needs to provide the whole context at all times (unless asked for specific elements) - in exactly the same manner as we can see in the accessibility tree, otherwise we need to do it manually and that kind of makes the MCP less usable for accessibility.

[OrKoN]

@BogdanCerovac this looks like a bug in Puppeteer (we will fix it). If you have more examples, please share!

[BogdanCerovac]

@OrKoN thanks, will get back to you soon.