Why the accessibility tree matters
Chrome's agentic browsing guidance says agents review the accessibility tree to identify interactive elements. A visible button without a programmatic name can therefore block a screen-reader user and leave an agent guessing about the action.
The tree is not a second website. It is a derived representation of the rendered page. Native elements, correct labels and valid relationships usually produce a stronger result than adding broad ARIA after the interface has already become ambiguous.
Signals worth inspecting
Lighthouse highlights names and labels, tree integrity and visibility as agent-centric accessibility signals. These are useful deterministic checks, but they do not prove that a complete customer journey works.
- Controls expose unique, task-relevant accessible names.
- Roles match behavior, and parent-child relationships are valid.
- Interactive content is not hidden from the accessibility tree.
- Disabled, expanded, selected, invalid and busy states update correctly.
- Form errors are connected to their fields and provide a recovery path.
Test the task, not only the node
A control can pass a label check and still fail the journey. The name may be technically present but ambiguous among repeated actions. A calendar may expose buttons yet lose the selected date after navigation. A modal may trap focus or hide the final state.
Pair static checks with an agent scenario that has a defined goal, allowed actions and deterministic final-state assertion. Record the accessibility snapshot and the visible state at the point of failure so an engineer can compare both representations.
Keyboard behavior completes the contract
A named control is not usable when focus cannot reach it, activation behaves differently from the native pattern or a modal returns focus to an unknown location. Test the same journey with keyboard input because it exposes ordering, focus management and composite-widget defects that a static tree snapshot cannot show.
Prefer native HTML behavior. When a custom widget is necessary, follow an established keyboard pattern and verify focus order, visible focus, escape behavior and the selected or expanded state after every action.
Dynamic states need observable recovery
Loading, validation, empty, error and success states must remain available to people and agents. A visual spinner without an accessible busy state, an error detached from its field or a toast that disappears before inspection can turn a recoverable issue into a blocked task.
Capture the visible UI and accessibility tree before and after the transition. Assert that the intended object, form value or server state changed exactly once, then verify that a retry cannot create a duplicate action.
- Expose current busy, invalid, expanded, selected and disabled states
- Associate instructions and errors with the affected control
- Move focus only when the change requires immediate attention
- Keep success confirmation available long enough to verify
Accessibility does not replace layout stability
Chrome also identifies Cumulative Layout Shift as an agentic browsing signal. An agent may resolve a target from semantics and still click the wrong location if late content moves the interface during the action window.
Track CLS for the page and target movement around important actions. Reserve media dimensions, avoid injecting banners above active controls and make loading states match the final layout.
Accessibility checks for an agent-readiness audit
- Prefer native elements and verify custom widgets against an established interaction pattern.
- Capture the accessibility tree before and after important state changes.
- Compare visible labels with accessible names for repeated controls.
- Run primary actions by keyboard and an accessibility-tree-driven executor.
- Verify errors, loading and success states through deterministic assertions.
- Measure CLS and target displacement during action windows.
Primary sources
- Accessibility for agentsChrome for Developers
- Lighthouse agentic browsing scoringChrome for Developers
- The accessibility treeweb.dev
- ARIA Authoring Practices GuideW3C Web Accessibility Initiative
