Accessibility Tree View Chrome: Inspect UI Fast

To view the accessibility tree in Chrome, open DevTools, select the Elements panel, and open the Accessibility pane in the sidebar; to see the whole page as a tree, tick the full-page accessibility tree toggle at the top of that pane. Chrome computes each node's name, role, and state from the DOM and ARIA, and the accessibility tree view in Chrome shows you exactly what a screen reader or an automation tool will read. Most guides stop at "here is the pane," but the part that matters for QA and for AI agents is what the tree is for: it is the machine-readable name of every control, and that name is what makes a bug report or an agent instruction unambiguous.

If you file bugs against a web app, the accessibility tree is the difference between "the blue button" and a node you can name. A screenshot shows pixels; the tree shows button "Submit Order" with its state and computed name, which is a target a developer or agent can act on without guessing.

How do you open the accessibility tree view in Chrome?

Open the accessibility tree view in Chrome in four steps. Each one takes seconds once you know where the pane hides.

1. Open DevTools with Cmd+Option+I (or right-click any element and choose Inspect).
2. Select the Elements panel, then find the Accessibility tab in the right-hand sidebar. If it is hidden, click the >> overflow chevron to reveal it.
3. Click any node in the DOM to see its computed accessibility properties on the right: Name, Role, and the full ancestor chain.
4. To browse the page as a tree instead of node by node, tick Enable full-page accessibility tree at the top of the pane, then click the reload icon and use the tree view.

There is a second, lower-level route. Navigate to chrome://accessibility, and you get a raw dump of the accessibility tree for every open tab, with toggles for web and native accessibility. This page is verbose, but it is the ground truth when the DevTools pane looks incomplete.

The accessibility tree is not the DOM. It is a filtered, computed layer the browser builds on top of the DOM specifically for assistive technology, so an element that exists in HTML can be absent from the tree if it is hidden or has aria-hidden set.

What does each accessibility tree node show?

Each node shows a computed name, a role, a set of states, and the source of that name. Those four properties are what a screen reader announces and what an automation locator matches against.

The name is computed by the accessible name algorithm, which walks a priority order: aria-labelledby, then aria-label, then a native label or the element's text content, then attributes like title or placeholder. The computed name, not the visible text, is what assistive tech reads, which is why a button showing an icon with no label reads as an empty node.

The role tells the receiver what kind of control it is: button, textbox, checkbox, link. The state captures runtime facts like disabled, expanded, checked, or focused. The source panel in Chrome shows which attribute produced the name, so you can see whether a name came from an aria-label or leaked in from surrounding text.

Reading nodes in Chrome maps almost one to one onto reading them on macOS. If you know how to use the Accessibility Inspector, the columns are the same: role, title, value, and a parent chain, just surfaced by a different tool.

Accessibility tree in Chrome vs the macOS AX tree

Chrome's accessibility tree and the macOS AX tree describe the same idea in two vocabularies. Chrome speaks ARIA roles; macOS speaks AX roles, and the browser bridges them so the operating system can expose web content to native assistive tech. The accessibility tree view Chrome ships in DevTools is the web-facing side of that bridge; the Accessibility Inspector on macOS is the native side.

The bridge is where the two meet. Chrome exposes its rendered page to macOS as an AXWebArea, so a native tool asking the OS "what element is under this point" gets a real answer inside a browser window, not just a screenshot. That is also what the macOS Accessibility API is used for beyond screen readers: any tool can query the named element under the pointer.

Two gotchas trip people up. Chromium builds its AX tree lazily to save memory, so a native tool often has to set AXManualAccessibility and retry for about 150ms until labeled nodes appear. And when a point lands on a bare AXGroup, a well-built tool descends to the deepest labeled child rather than reporting the empty group, using Chromium identity attributes like AXDOMIdentifier and AXDOMClassList to name a title-less node.

Why does the accessibility tree matter for bug reports and agents?

The accessibility tree matters because it turns "the thing on screen" into a named, structured target that a human or an AI agent can act on without a clarifying question. A report that says button "Submit Order" (disabled) is executable; a report that says "the button doesn't work" is a conversation.

This is the practical payoff of learning the accessibility tree view Chrome exposes: once you can read a node's role, name, and state, you stop writing bug reports in pixels and start writing them in nouns the codebase already uses. The same node names show up in your ARIA attributes, your test locators, and your component props, so a report anchored to them points straight at the source.

For AI coding agents, this is the whole game. How AI agents know which UI element you mean depends on whether you hand them a resolved node or a picture to interpret. Feed an agent the role, computed name, and frame, and it can look up the label in the source; feed it a PNG, and it has to OCR and guess.

This is why a capture tool built on the accessibility tree beats one built on pixels. On macOS you can hold ⌥⌘A, point at any control in a browser or a native app, and speak the issue; the tool resolves the element via the same tree you just inspected in Chrome, attaches a confidence score, and files a named target. When AX is genuinely empty, on a canvas or a WebGL surface, it falls back to on-device OCR rather than pretending it resolved a node.

For QA engineers who want to file named, reproducible reports from the accessibility tree without opening DevTools every time, PinVari resolves the element you point at for a one-time $39, on-device, with nothing uploaded by default.

FAQ

How do I view the accessibility tree in Chrome?

Open DevTools with Cmd+Option+I, select the Elements panel, and open the Accessibility tab in the sidebar. Click any node to see its computed name, role, and state, or tick "Enable full-page accessibility tree" to browse the whole page as a tree.

What is the difference between the DOM and the accessibility tree?

The DOM is the full HTML structure; the accessibility tree is a filtered, computed layer built from it for assistive technology. Hidden elements or nodes with aria-hidden exist in the DOM but are absent from the accessibility tree, so the two are never identical.

Why is a node's accessible name empty in Chrome?

The accessible name is computed from aria-labelledby, aria-label, a native label, or text content, in that order. An icon-only button with none of those reads as an empty node, which is a real accessibility bug that a screen reader would announce as nothing.

How do I inspect the accessibility tree on macOS instead of Chrome?

Use the Accessibility Inspector that ships with Xcode. It shows the AX role, title, value, and parent chain for any app, native or browser, and lets you inspect the element under the pointer, mirroring what Chrome's DevTools pane shows for web content.

Can automation tools read the accessibility tree?

Yes. Screen readers, test frameworks like Playwright, and native capture tools all read the accessibility tree rather than pixels. That is why role and computed name are more reliable locators than CSS position, since they stay stable when the layout shifts.

Does the accessibility tree work inside Electron apps?

Yes, because Electron embeds Chromium, which builds an accessibility tree. The catch is that Chromium builds it lazily, so a tool inspecting an Electron window may need to force the tree with AXManualAccessibility and retry before labeled nodes appear.