How are the Agentic Browsing accessibility audits derived, and is there a plan for task-level checks?

[ericovirgy]

I read the Agentic Browsing category docs (https://developer.chrome.com/docs/lighthouse/agentic-browsing) and have two questions.

1. Is agent-accessibility-tree derived from Playwright's ariaSnapshot({ mode: 'ai' }), from axe-core, or from Chrome's own accessibility tree?
2. 2. The docs describe audits that read a page. Is there interest in behavioural, task-level checks (an agent tries a goal, success is asserted on the final page state), or is that out of scope for Lighthouse?
      Context: I maintain an open-source CLI, https://github.com/ericovirgy/agentic-web-check, that runs scripted tasks with programmatic assertions in a live browser. It does not re-implement Lighthouse audits, and a Lighthouse adapter is on its roadmap. I am asking so I do not duplicate what is planned.

[antropos17]

For question 1, the current code path is axe-based. At ac1b8fa, the Accessibility gatherer calls axe.run; agent-accessibility-tree filters Accessibility.violations through TARGET_RULES. That path does not consume Playwright's ariaSnapshot.

I can't answer the maintainers' roadmap question. A useful task-level example is AEGIS #1217: activate a worker selector by keyboard and assert that the selected state follows the correct worker. An initial page check alone would not establish that transition. The issue is open and unassigned if anyone wants to help with the component case.

I maintain AEGIS; AI-assisted reply. This is a source read, not a Lighthouse runtime test.