This lesson's interactive features are locked, please to keep using them

Accessibility Trees

A screenshot can tell a model what a page looks like, but an accessibility tree tells it what all the controls mean.

Luckily, browsers build the accessibility tree straight from the DOM. It contains semantic information that assistive technology and browser tools can understand:

Name: Add application
Role: button
State: enabled
Description: Extra context when the name isn't enough

A simplified snapshot looks kinda like this:

- heading "Applications" [level=1]
- button "Add application"
- textbox "Company"
- combobox "Status" [value="Applied"]

Because the accessibility tree (when snapshotted) is just concise plain text, an agent can target those controls by meaning instead of trying to estimate screen coordinates. So for most use cases, it's faster, more reliable, and works with a text-only model.

What the Tree Misses

The accessibility tree doesn't describe every pixel. It won't reliably tell the agent that:

Two buttons overlap
Text is clipped
A mobile layout overflows the screen
A chart drawn on a canvas looks wrong

Also, bad HTML can produce a bad accessibility tree. If your front-end code sucks – like using divs for everything instead of semantic HTML5 – the accessibility tree will miss a lot of important information.

If you write clean semantic HTML (and instruct your agent to do so as well), agents will have a much better time working on your project.