Accessibility Inspector Mac: Debug UI Elements Fast

Accessibility Inspector Mac is the free, Xcode-bundled tool that reports the role, label, value, and screen frame of any UI element under your cursor, whether that element lives in a native app, a browser tab, or an Electron window. You launch it from Xcode's Open Developer Tool menu, point it at any running app, and it hands back the exact accessibility node your code, your tests, or an AI coding agent will query.

Most walkthroughs stop at "hover and read the label," which hides the part that actually saves you time: the inspector shows you the interface the way software consumes it, not the way your eyes do.

What does Accessibility Inspector on Mac actually do?

Accessibility Inspector reads the accessibility tree, the parallel model of the UI that macOS builds for assistive tech and automation. Every control on screen becomes a node, and the inspector lets you interrogate any node one at a time.

Point it at a button and it tells you four things that matter. The role (AXButton, AXTextField, AXLink), the label a VoiceOver user would hear, the current value if the control holds one, and the frame in screen coordinates. That last field is what maps a pixel back to the object that owns it.

Under the hood every one of those attributes comes from AXUIElement, the type behind the entire macOS Accessibility API. Accessibility Inspector Mac is really just a friendly window onto the same calls you would make in code with AXUIElementCopyElementAtPosition and AXUIElementCopyAttributeValue.

That equivalence is what makes the inspector so useful as a debugging tool rather than a curiosity. Whatever the inspector shows you under the cursor is exactly what your code receives when it hit-tests the same point, so it becomes the fastest way to answer "is this element actually named, and does its frame make sense" before you write a single automation. When your test can find the element but the inspector cannot, or the reverse, you have learned something concrete about where the bug lives.

How do you use Accessibility Inspector Mac step by step?

You do not need to write any Swift to get value out of it. The whole workflow is point, read, verify.

First, launch it: open Xcode, then Xcode → Open Developer Tool → Accessibility Inspector. If you have the Xcode command line tools but not the full app, install Xcode from the App Store once and the inspector comes with it.

Second, choose a target app from the dropdown in the inspector's toolbar, or leave it on "all processes." Then click the crosshair (the inspection-pointer button) and hover over any control in that app.

Third, read the panel. The Basic section shows role, label, value, and frame. Turning on the Screen Reader simulation shows how VoiceOver would announce that node, which is how you confirm the label a real user hears.

Every Accessibility Inspector Mac session ends the same useful way: you now know whether the element you care about has a real name, and where it lives, before you write a line of test code or ask an agent to touch it.

Accessibility Inspector vs the other ways to see the tree

The inspector is not the only way to look at UI structure. Depending on whether you are debugging a web page, a native app, or an Electron window, a different tool gives you the cleanest view. Here is the honest side-by-side.

The pattern is clear. For anything that renders inside a native window, including the Electron apps most of us run all day, Accessibility Inspector Mac is the fastest path from "which control is this" to "here is its exact node." For pure web work, the Chrome accessibility tree view gives you the name-source chain the inspector cannot.

If you want the deeper theory behind why these tools all report the same shape, the accessibility tree explainer covers how browsers and native apps build it from different runtimes.

Why does an empty label break screen readers and AI agents alike?

Because a node with no role and no name is invisible to everything that reads the tree. This is the single most common finding when you actually inspect a "broken" control, and it explains failures that look unrelated on the surface.

A <div> styled to look like a button, or a custom NSView that never sets accessibilityLabel, shows up in Accessibility Inspector as a bare group with an empty name. A control with no accessible name simply is not there for a screen reader, a UI test, or an AI coding tool.

That last case is where it stings for developers shipping with agents. When Claude Code or Cursor keeps editing the wrong element, the root cause is frequently that the element you meant has no name, so the tool falls back to guessing from nearby pixels. Inspect it first and you often find the real bug in seconds.

There is also a class of surfaces where the tree is empty by design. Canvas elements, WebGL scenes, games, and some custom-drawn Electron views expose nothing to the accessibility layer, so the inspector reports a generic group with no children. On those surfaces the only correct fallback is on-device OCR of the region plus a confidence score, never a silent guess.

From inspecting elements to acting on them

Accessibility Inspector is a read-only lens. It tells you what a node is, but you still have to translate that into a test selector, a bug report, or a prompt your agent can act on. That translation step is where the time actually goes.

This is the layer PinVari automates. You hold ⌥⌘A, circle any control on screen, and speak; PinVari resolves the named element under your ink straight from the accessibility tree, exactly the node the inspector would show you, and attaches a confidence score plus whether you circled it or dwelled on it. It reads the deictic "this" and "that" against a timestamped pointer trail, so the word binds to a real AXUIElement, which is the same mechanism that lets AI agents know which UI element you mean.

It runs on-device, ships with no API keys, and hands your own agent a resolved, executable instruction over a local MCP server on 127.0.0.1. It is a one-time $39 launch license, not a subscription. Think of it as Accessibility Inspector that also speaks to Claude Code, Cursor, Codex, or Zed for you.

FAQ

Where is Accessibility Inspector on Mac?

It ships with Xcode. Open Xcode, then choose Xcode → Open Developer Tool → Accessibility Inspector from the menu bar. If you do not see it, install the full Xcode app from the App Store once, since the standalone command line tools do not include the inspector.

Is Accessibility Inspector Mac free?

Yes. It is bundled with Xcode, which is a free download from the Mac App Store. There is no separate purchase, license, or subscription for the inspector itself.

Can Accessibility Inspector read Electron apps?

Yes, though Electron and Chromium build their accessibility tree lazily, so the first read can return a bare group. Tools that query these apps in code often set AXManualAccessibility and retry after roughly 150ms until real labels appear, and the inspector benefits from the same warmup once the app has been interacted with.

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

The DOM is the full document a browser renders; the accessibility tree is a filtered, computed view derived from the DOM plus ARIA, containing only meaningful controls with resolved roles and names. The Chrome accessibility tree view and Accessibility Inspector both show the computed version, not the raw markup.

Why does my element show an empty label in the inspector?

It has no accessible name, usually because it is a styled <div> or custom view with no role, aria-label, or accessibilityLabel set. Canvas, WebGL, and some game surfaces also expose nothing, in which case there is no label to read and OCR is the only fallback.

Can AI coding agents use the same data Accessibility Inspector shows?

Yes, and it makes them far more accurate. Reading the accessibility node lets an agent target AXButton "Save" instead of guessing which button in a screenshot you meant, which cuts wrong-element edits and the token cost of shipping full images to the model.