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.

[arthurgousset]

+1 from me on this thread. Thanks for raising this @BogdanCerovac ! <3

[BogdanCerovac]

@OrKoN - I thought about it and decided to run a simple test - I provided an "kitchen sink" HTML example with as much elements as possible (please check index.html) and taking a "snapshot" (results in snapshot.txt).

I can confirm that we really don't get the whole semantics of all relevant elements for accessibility when I compare it to accessibility tree in DevTools. It seems that snapshot is mostly considering text and some semantics like headings and some form elements, but totally missing out on landmarks and other really important semantic elements.

Didn't have the time to do a 1:1 check, but some findings having them side by side - I noticed:

• regions are missing from snapshot - for example heading, navigation, main, groups, complementary, contentinfo
• even some headings seem to be missing
• canvas was missing (its fallback text was there though)
• semantics of some "special" elements is missing - like for example element
• table semantics missing as pointed out in some of my previous posts

Then I checked the snapshot directly with latest stable Puppeteer and yes - it makes sense now - MCP only returns what Puppeteer is returning and in my example it is obvious that Puppeteer does not return the whole tree. I've tried both interestingOnly:false (default) and interestingOnly:true (Puppeteer options for Accessibility.spanshot()). Same output - missing crucial semantics. If possible - can you please discuss this with Puppeteer team (I see there are some related issues there, I suspect I am not the first one to discover this (?)).

I then remembered I was able to get the whole accessibility tree from Puppeteer back in the days when testing Puppeteer for accessibility automatic testing, and I remembered I just needed to use the CDP for extraction. So I did that now, with latest version (using still experimental getFullAXTree) - and I then got the whole semantics there (I just checked it quickly, but it seems way better at least - please check accessibility_tree_output-from-CDP.json).

This leads me to ask that MCP provides whole semantics just like we can get from the CDP via getFullAXTree (if snapshot is not an option or at least for the time when snapshot is missing on the whole semantics).

Output should ideally be in markdown or YAML, but I guess AI can also use JSON (considering token usage, I guess we should allow multiple options if possible), so that we can provide this output as context for AI agents etc.

[OrKoN]

Thanks, I filed an issue for this in Puppeteer. Note that Puppeteer does use getFullAXTree and we are also the Puppeteer team. Do you have links to specific existing issues in the Puppeteer repo you found?

[BogdanCerovac]

@OrKoN - thank you very much, I've seen you made the improvement on the Puppeteer repo and it's already out (https://github.com/puppeteer/puppeteer/blob/main/CHANGELOG.md#24260-2025-10-21).

Will check it out in the following days, but at first glance it looks we now have way better accessibility context all the way from Puppeteer to MCP.

As for other issues - I think https://github.com/puppeteer/puppeteer/issues/6311 is very relevant here. URLs for links (where href is provided) are extremely important, especially when we have multiple links with no programmatic context and exactly same link names (for example "Read more" etc.).

I see that you actually had a fix for this here, perhaps: https://github.com/puppeteer/puppeteer/issues/6311#issuecomment-2168034656

[OrKoN]

Thanks for the reminder about https://github.com/puppeteer/puppeteer/issues/6311, totally forgot about that one. So right now we added landmarks to be returned by default, and we added an option on the MCP server side to get the complete a11y tree. The url attribute will be out in one of the next releases.

[BogdanCerovac]

@OrKoN - thanks for the improvements and fixes. I re-tested the outputs with latest versions of MCP and Puppeteer and see that interestingOnly: true is not suitable for my accessibility usecases as it does not show all the relevant accessibility semantic layers (for example groups like lists and fieldsets etc.).

But I can use take_snapshot verbose that runs interestingOnly: false behind the scenes to get to the whole tree. I just tested it and it worked well. The only thing that is missing are the newly provided urls (that are now available because of https://github.com/puppeteer/puppeteer/issues/6311, thanks).

Not sure if people would appreciate the urls of the links also in the "normal" take_snapshot (that is not verbose), but I think we need the urls at least in the verbose mode.

[BogdanCerovac]

@OrKoN - tested this some more and I don't see an option to set the "root" for the snapshot. That could be used when pages are too complex and context window gets too large for AI agent.

It could also be used to check a single element or a limited tree of elements. As far as I can see from https://pptr.dev/api/puppeteer.snapshotoptions (root) we could perhaps expose this root via MCP?

[OrKoN]

I think having the root option is not very useful without some sort of filtering/pagination. In the next release, we will allow saving snapshots to a file so they could be processed with grep or other tools. That should help in some instances to manage larger pages. Could you please file a separate feature request for pagination/root? Please include some examples how you would prompt the LLM to make use of the root option!

[sarahbethfederman]

Is the includeIframes option exposed? This would be very helpful for us!

[OrKoN]

Iframes are included by default (there is no option to disable iframes).

[sarahbethfederman]

Oh, that's confusing, it looked to be turned off by default in the above links https://github.com/puppeteer/puppeteer/blob/main/packages/puppeteer-core/src/cdp/Accessibility.ts#L208

[OrKoN]

It's off by default in Puppeteer but not in the MCP server https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/src/McpContext.ts#L481