How to Use Accessibility Inspector on macOS

To use Accessibility Inspector on macOS, open Xcode, choose Xcode > Open Developer Tool > Accessibility Inspector, then use the target crosshair to point at any on-screen element and read its role, label, value, and frame in the inspection panel. It is a free tool bundled with Xcode that exposes the same accessibility tree the operating system builds for VoiceOver, which is also the exact data a coding agent needs to act on the right control. Most tutorials on how to use Accessibility Inspector treat it as a VoiceOver audit tool and stop there, missing that the AX tree it reveals is the ground truth behind "which element did the user mean."

If you live in Claude Code or the Codex CLI, you have felt the failure mode: you describe a UI bug in a paragraph, paste a screenshot that costs tokens, and the agent still edits the wrong element. Accessibility Inspector is how you see, by hand, the named object the agent should have received in the first place.

What is Accessibility Inspector, and where do you find it?

Accessibility Inspector is a developer tool bundled with Xcode that lets you inspect the accessibility properties of any element on screen. It reads the macOS accessibility tree, the same structure VoiceOver navigates, and shows you each element's role, title, value, frame, and parent chain.

You find it inside Xcode. Open Xcode, then choose Xcode > Open Developer Tool > Accessibility Inspector from the menu bar. You do not need a project open, and the Inspector runs as its own app once launched, so you can pin it to your Dock.

At the top of its window is a target selector: a small crosshair icon and a dropdown to choose which process to inspect. The crosshair is the whole point, because it hit-tests the element directly under your pointer and fills the panel with that element's attributes.

How to use Accessibility Inspector step by step

Here is how to use Accessibility Inspector to inspect a single element end to end. The whole loop takes under a minute once the tool is open.

1. Launch it from Xcode > Open Developer Tool > Accessibility Inspector.
2. In the target menu at the top left, pick the app you want to inspect, or leave it on the system-wide target to inspect anything.
3. Click the crosshair (the point-and-inspect button), then move your pointer over the control you care about. The panel updates live as you move.
4. Click, or press the inspection hotkey, to lock the current element so it stops following the pointer.
5. Read the Basic section: Role, Subrole, Label, Value, and the element's frame in screen coordinates.
6. Expand the hierarchy to walk the parent chain up to the window, or drill into children.

The attributes you read map directly to what the Accessibility API returns in code. The Inspector's "Role" is the element's AXRole, "Label" is AXTitle or AXDescription, and the frame is the same rectangle AXUIElementCopyElementAtPosition reports. The macOS Accessibility API explained covers how those calls resolve an element from a screen point.

How do you read the accessibility tree it shows?

You read the accessibility tree by treating each element as a named object with a role, a label, a value, a frame, and a parent chain, and by checking whether the element you care about actually carries a label. An unlabeled node is the root cause of most ambiguity.

The tree is hierarchical. A window contains groups, groups contain controls, and each node advertises its role. A well-built app gives every interactive control a stable AXTitle, so AXButton "Submit Order" is unambiguous no matter where it moves on screen. The deeper explainer on what the accessibility tree is walks through the roles you will see most.

The failure cases are worth memorizing. Some containers expose only AXGroup with no title, so the meaningful label lives on a child. Canvas-drawn and some game surfaces expose almost nothing, because they paint pixels instead of building a tree. In those cases the Inspector shows you an empty or generic node, which is the honest signal that pixel-based fallbacks are the only option.

The Inspector is a microscope, not a pipeline. It is superb for looking at one element by hand, and it is not built to package that element and route it to your coding agent.

How to inspect the accessibility tree in Chrome

To inspect the accessibility tree view in Chrome, open DevTools, go to the Elements panel, and select the Accessibility tab in the sidebar, which shows the computed accessibility properties for the selected DOM node. Chrome derives this tree from the DOM and ARIA attributes, so it reflects the web content, not the surrounding native app.

There is a wrinkle that matters for anyone building on top of the tree. Chromium builds its full accessibility tree lazily, only when an assistive client asks for it, so a fresh Chrome or Electron window can report a mostly empty tree at first. Setting the AXManualAccessibility attribute and retrying after a short delay is what forces the tree to populate. The accessibility tree view in Chrome guide goes deeper on the DOM-to-AX mapping.

Chromium also exposes identity attributes that a plain title does not. When a node has no visible label, AXDOMIdentifier and AXDOMClassList can give a title-less element a usable name, which is often the only handle you get on a custom web component.

What does Accessibility Inspector miss for AI workflows?

Accessibility Inspector misses everything past inspection: it reveals the element but does not resolve overlays, package the result, or route it to an agent. For a manual audit that is fine. For handing a coding agent an unambiguous target, three gaps show up that a production resolver has to close.

First, a topmost overlay poisons a naive hit-test. If a tool draws its own window over the screen, AXUIElementCopyElementAtPosition resolves to that overlay, not the app underneath. The fix is to walk the on-screen window list and hit-test the real app beneath, excluding your own window from the chain.

Second, a bare AXGroup under the pointer carries no label, so a resolver has to descend to the deepest labeled child to recover a usable name rather than reporting a nameless container.

Third, confidence has to be explicit. When the resolved element is ambiguous or the label is weak, the honest behavior is to ask rather than silently guess, and below a confidence threshold the target should be confirmed. This is precisely why Claude Code sometimes fixes the wrong element: it received a screenshot and a description instead of a resolved, named target with a confidence score.

The payoff of closing these gaps is a clean handoff. How AI agents know which UI element you mean comes down to whether the element arrived as structured data, the role, label, frame, and parent chain, or as pixels to interpret. A resolved element is a target; a screenshot is a guess.

A point-and-speak tool automates the whole path the Inspector only starts. You hold ⌥⌘A, circle or point at a control, and speak the change; it resolves the named AXElement with a confidence score, transcribes on-device, and hands the agent the target over a local MCP server. For developers who want that resolution wired straight into Claude Code, Cursor, or Codex instead of alt-tabbing to the Inspector, PinVari ships it at a one-time $39 launch price, on-device, with no API keys.

FAQ

Where is Accessibility Inspector on a Mac?

It ships inside Xcode. Open Xcode and choose Xcode > Open Developer Tool > Accessibility Inspector from the menu bar. You need Xcode installed from the App Store, but you do not need a project open, and the Inspector runs as a standalone app you can keep in the Dock.

How do I inspect a specific element with Accessibility Inspector?

Click the crosshair target button, then hover over the control; the panel updates live with the element's role, label, value, and frame. Click or press the lock hotkey to freeze the current element so you can read and copy its attributes without the selection following your pointer.

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

The DOM is the document structure a browser parses from HTML, while the accessibility tree is the derived structure that assistive technology and the Accessibility API navigate. On the web the tree is computed from the DOM plus ARIA; in a native macOS app there is no DOM, and the AX tree is the primary structure.

Why does an Electron or Chrome app show an empty accessibility tree?

Chromium builds its accessibility tree lazily, only when an assistive client requests it, so a freshly opened window can look empty. Setting the AXManualAccessibility attribute and retrying after roughly 150 milliseconds forces the tree to populate with labeled elements.

Can Accessibility Inspector give data to an AI coding agent?

Not directly. It is built for manual inspection and audits, so it shows you the element but does not package or route it. To hand an agent a target you need something that resolves the element and passes its role, label, frame, and confidence over an integration or a local MCP server.

What does Accessibility Inspector not capture?

It does not resolve overlays that sit above your target, it will not descend a bare AXGroup to find the labeled child for you, and it reports little on canvas-drawn or game surfaces that never build a tree. Those cases need overlay-aware hit-testing, labeled-descendant walking, and an OCR fallback respectively.