Accessibility Inspector Mac: Debug UI Elements Fast

Accessibility Inspector Mac is the free Xcode tool that reports the role, label, value, and screen frame of any UI element under your cursor. You launch it from Xcode's Open Developer Tool menu, point it at a running app, and it hands back the same node your tests or an AI coding agent will query.

Most walkthroughs stop at "hover and read the label." The useful part is that the inspector shows 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 you can interrogate 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 maps a pixel back to the object that owns it. Under the hood every attribute comes from AXUIElement, the type behind the macOS Accessibility API.

Accessibility Inspector Mac is a friendly window onto the same calls you would make with AXUIElementCopyElementAtPosition and AXUIElementCopyAttributeValue. Whatever it shows under the cursor is exactly what your code receives at that point.

That makes it a debugger, not a curiosity. It is the fastest way to answer "is this element named, and does its frame make sense" before you write a line of automation.

When your test can find the element but the inspector cannot, or the reverse, you have learned where the bug lives.

How do you use Accessibility Inspector Mac step by step?

You do not need to write 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 only have the command line tools, install the full Xcode app once and the inspector comes with it.

Second, choose a target app from the dropdown, or leave it on "all processes." Click the crosshair and hover over any control.

Third, read the panel. The Basic section shows role, label, value, and frame.

Turn on the Screen Reader simulation to hear how VoiceOver would announce that node. That is how you confirm the label a real user hears.

Every Accessibility Inspector Mac session should end the same way. You now know whether the element has a real name, and where it lives, before you write a test 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. The cleanest tool depends on whether you are debugging a web page, a native app, or an Electron window.

Accessibility Inspector

• Platform: macOS
• What it shows: Role, label, value, frame under the cursor
• Best for: Native apps and Electron windows

Chrome DevTools a11y pane

• Platform: Browser
• What it shows: Computed role, name, and name-source chain
• Best for: One web element at a time

chrome://accessibility

• Platform: Browser
• What it shows: The full internal tree for a tab
• Best for: A whole-page audit

VoiceOver Utility

• Platform: macOS
• What it shows: How a node is actually announced
• Best for: Real assistive-tech behavior

Xcode view debugger

• Platform: macOS / iOS
• What it shows: View hierarchy and layer geometry
• Best for: Layout, not semantics

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" to "here is its node." For pure web work, the accessibility tree view in Chrome gives you the name-source chain the inspector cannot.

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

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

A node with no role and no name is invisible to everything that reads the tree. This is the most common finding when you inspect a "broken" control.

A <div> styled as a button, or a custom NSView that never sets accessibilityLabel, shows up 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 if you ship with agents. When Claude Code or Cursor keeps editing the wrong element, the element you meant often has no name, so the tool guesses from nearby pixels.

Inspect it first. You often find the real bug in seconds.

Some surfaces are empty by design. Canvas, WebGL, games, and some custom-drawn Electron views expose nothing, so the inspector reports a generic group with no children.

On those surfaces the only honest 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 turn that into a test selector, a bug report, or a prompt an agent can act on.

That translation is where the time goes.

This is the layer PinVari automates. You hold ⌥⌘A, circle any control, and speak.

It resolves the named element under your ink from the accessibility tree, the same node the inspector would show. It attaches a confidence score and whether you circled it or dwelled on it.

It binds "this" and "that" against a timestamped pointer trail, so the word maps to a real AXUIElement. That 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 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; 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 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. 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 from the DOM plus ARIA, containing only meaningful controls with resolved roles and names. Chrome's accessibility pane 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. 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 more accurate. Reading the accessibility node lets an agent target AXButton "Save" instead of guessing which button in a screenshot you meant. That cuts wrong-element edits and the token cost of shipping full images to the model.