The accessibility tree shows a web page the way software can operate it: not how things look, but what they are and what they are called. To build it, a browser first reads the HTML and turns it into the Document Object Model (DOM), a tree structure of all the page’s elements, attributes, and text. From the DOM, the browser derives the accessibility tree and exposes it through the operating system’s accessibility interfaces to assistive technologies, such as screen readers that read pages aloud to blind and visually impaired people. It is a tree because its elements are nested: a navigation contains a list, and the list contains links.

Role, name, and state

Each element in the accessibility tree is described by a few properties:

  • Role: what kind of element it is, such as a button, link, heading, text field, or navigation.
  • Name: what it is called, such as “Book an appointment” for a button or “Email address” for a form field.
  • State: whether a checkbox is checked, a menu is expanded, or a button is currently disabled.

Depending on the element, a value, such as the text in an input field, and an additional description can be added. From these properties, a screen reader announces, for example, “Book an appointment, button.”

Native HTML elements—those defined in the HTML standard—come with their role built in. A line such as “<button>Book an appointment</button>” appears in the accessibility tree as a button named “Book an appointment.” A div element, by contrast, is a generic container with no meaning of its own: if it only looks and behaves like a button through styling and scripts, it still does not appear in the accessibility tree as a button. Building pages from the right elements is what semantic HTML is about.

The accessible name

The accessible name states what an element is for and distinguishes it from other elements on the page. The browser computes it from the code according to fixed rules:

  • Links and buttons: usually from their visible text.
  • Form fields: from the associated label element.
  • Images: from the alternative text in the alt attribute.
  • Elements without visible text: A button that only shows an icon can get its name from the aria-label attribute. The attribute is part of WAI-ARIA, a standard from the World Wide Web Consortium (W3C) for the roles, names, and states of elements.

The W3C’s guidance on names recommends preferring visible text and native HTML techniques and choosing short, distinctive names that state the purpose: “Close,” not “X.” Placeholder text in a field or the tooltip text of a title attribute, which appears when the mouse hovers over an element, is only a fallback the browser resorts to, and the guidance advises against relying on it. If a name is missing altogether, the accessibility tree only shows that there is, say, a text field, not whether it expects a name, an email address, or a phone number.

How AI agents use the accessibility tree

AI agents complete tasks on websites on people’s behalf, such as comparing offers or sending an inquiry. According to Google, such agents may analyze screenshots, inspect the DOM, and interpret the accessibility tree. In the documentation for its auditing tool Lighthouse, Google calls the accessibility tree agents’ primary data model; on web.dev, it describes the tree as a kind of map that leaves out visual decoration and shows what can be used. Anthropic documents this approach as well. Its browser use tool, which developers use to let Claude operate websites in a browser, returns a page’s accessibility tree as text. Each element carries a reference that Claude can use in later steps to click it or fill it in; the tool also works with screenshots.

Whatever is missing from the accessibility tree or described incorrectly is hard for an agent to find and understand. Google’s Lighthouse documentation notes that missing labels can keep people with visual disabilities and agents alike from completing a task. A complete accessibility tree thus partly determines whether an agent can get something done on a website, such as sending an inquiry or booking an appointment, which makes it one building block of an agent-friendly website.

The accessibility tree is built by the browser, so it matters for agents that open a page in a browser. An AI crawler that only fetches a page’s HTML does not build an accessibility tree; it only sees what the delivered HTML contains, not what JavaScript rendering adds in the browser.

Viewing and checking the accessibility tree

Chrome’s developer tools show what a page’s accessibility tree looks like: the view of the page’s elements can be switched from the DOM to the accessibility tree of the entire page, including each element’s role and name. In its experimental Agentic Browsing category, Google’s auditing tool Lighthouse automatically checks part of it: the accessibility audits that matter most for agents, such as whether every interactive element has a name and whether roles and the nesting of elements are valid.

Clear names and the right elements help screen reader users and AI agents alike. This is where work on the accessibility tree overlaps with web accessibility, which makes websites usable for people with disabilities.