macOS accessibility APIs and Electron apps: where the bridge actually breaks

They reach. Chromium implements the NSAccessibility informal protocol, so an Electron window does respond to AXUIElementCopyAttributeValue and friends. The reach is just not useful. Two things have to be true for an external AX agent to act on an element: the element has to exist in the tree, and it has to carry a role and name a model can dispatch on. Electron clears the first bar (the tree exists) but usually fails the second (the tree is mostly empty AXGroup nodes with no AXTitle or AXValue, because the underlying DOM is styled <div> soup with no aria-label or role attributes). So the right framing is not 'blocked', it is 'reached, but at a depth that does not let an agent do anything'.

Chromium does not build a full accessibility tree by default. It builds one when an AT client opens it, or when the embedder asks for it explicitly. Electron exposes this as the app-level property app.accessibilitySupportEnabled, which a developer can set to true to force-on at startup. It can also be forced via the Chromium command-line switch --force-renderer-accessibility, passed by appending it to Electron's commandLine. Without either, your AXUIElementCopyAttributeValue calls return a thin top-level tree (the window chrome, the menu bar) and a single AXGroup that represents the entire content area, no children. The reason most articles tell you to turn the flag on is that it gets you from one node to a few hundred nodes. They stop there. The flag does not promise the few hundred are labelled.

Because Chromium's accessibility tree is a translation of the DOM. It walks the live document, maps HTML elements and ARIA attributes to platform AX roles, and exposes the result. If the DOM is <div>...</div> nested ten deep with class names but no aria-label, no role, no semantic element, the translation is a stack of generic group nodes. Slack and Discord render most of their interactive surface this way. Notion does too. VS Code's editor surface is a custom canvas-like text widget that the AX bridge can describe at the line level but not at the token level. The conclusion is operational: --force-renderer-accessibility is a necessary toggle for these apps, never a sufficient one. The actual quality of the tree is the responsibility of the web app inside the shell.

A top-level AXApplication, an AXWindow with the workspace name in its title, a menu bar with the standard macOS menu items, and one giant AXGroup containing the entire content view. Inside that group there are a few hundred more AXGroup nodes with no name, occasional AXStaticText nodes that carry the visible message text, and very few buttons or roles. There is no 'Send message' button with role AXButton and title 'Send'. The agent cannot pick a target by role plus name the way it would on Mail or Finder or Apple Music. So the agent ends up reading the AXStaticText nodes for context, then either guessing coordinates from the bounding boxes in the AX dump, or falling back to a screenshot pipeline with OCR. Same problem in Discord, with a slightly thicker tree because their voice-channel widgets are slightly more semantic.

AXError.cannotComplete (raw value -25204). On macOS this single code is returned in three very different situations: the user revoked the system-wide Accessibility permission, the per-process TCC cache went stale after an OS update or app re-sign, or the target app simply did not implement NSAccessibility at the depth the call needs. The first two are permission states the user can fix by toggling Settings. The third is an app-shape problem the user cannot fix. An agent that maps cannotComplete to 'permission broken' will pop a settings dialog every time the user focuses an Electron app that did not opt in. Users hate that, and they will not trust an agent that nags. The fix is to disambiguate before deciding.

Probe a known-good control. When testAccessibilityPermission in Fazm's AppState.swift (line 480) gets AXError.cannotComplete from the frontmost app, it does not conclude anything yet. It calls confirmAccessibilityBrokenViaFinder at line 517. That function pulls the running com.apple.finder process and runs the same AXUIElementCopyAttributeValue against it. Finder always implements NSAccessibility and is always running on a Mac. If Finder also fails, the permission is truly stuck, the agent surfaces a Quit-and-Reopen dialog. If Finder succeeds, the original failure was app-specific: the agent logs the suspect app, marks it AX-incompatible for this session, and falls back to vision. A third tie-breaker exists for the case where Finder is not running (rare): probeAccessibilityViaEventTap at line 539 attempts to create a CGEvent tap, which queries the live TCC database and bypasses the per-process AX permission cache that can go stale on macOS 26 (Tahoe). Three layers, one call each, no nagging.

Partially. The flag flips Chromium from 'thin top-level tree' to 'full DOM-derived tree', which usually means the number of nodes in your AX dump goes up by an order of magnitude. The new nodes contain the visible static text in AXStaticText nodes, which helps the agent understand context. What does not change: the buttons inside the web app are still styled divs with no semantic role unless the web app added one. So 'click the third reaction button on the second message' is still guesswork. The fix that actually works lives upstream: Slack would have to add aria-label and role=button to the elements you want to act on. Until they do, the agent has to fall back to a vision pipeline for those interactions even with the flag on. The flag is necessary, not sufficient.

Better than Slack or Discord, worse than a native editor. Monaco exposes its line model through an ARIA live region with text content, which means an AX agent can read the visible buffer line by line via AXStaticText. It cannot place the cursor at column 17 of line 200 by addressing an AX element, because Monaco renders its cursor on a canvas. The agent ends up driving the editor via keyboard shortcuts (cmd-g for goto-line, cmd-f for find) instead of AX-level positioning. This is fine if the agent is doing high-level operations like 'open this file and run this command'. It is not fine if the agent needs surgical edits, in which case a real LSP or a direct file edit beats the AX path. Cursor inherits VS Code's tree wholesale.

Yes, and the failure mode is slightly different. Tauri renders content in the platform's native webview (WKWebView on macOS), and WKWebView's accessibility bridge to the host AX layer is even more conservative than Chromium's. The DOM is there, but the AT-side exposure is opt-in per webview and the resulting tree tends to be even sparser than Electron's. The same disambiguation pattern (probe Finder, fall back to vision) applies. The thing that changes is the runtime knob: there is no --force-renderer-accessibility equivalent for WKWebView, the developer has to enable it in their Cocoa setup at app build time.

If you run the Fazm agent locally, every accessibility tool call writes a file to /tmp/macos-use/<timestamp>_<tool>.txt with the exact AX tree the model received. Open the file in any editor. Each line is one element, format is [AXRole (subrole)] "title" x:N y:N w:W h:H, and the file header shows the element count and traversal time. Run a tool against Slack with --force-renderer-accessibility off, then run the same tool with the flag on. Diff the two files. You will see exactly where the bridge stopped translating, and you will see how much of the visible UI is still missing from the labelled-element view. That diff is the ground truth.

It is the honest answer for the apps inside the shell. Screenshot-and-coordinate agents (Anthropic's Computer Use, OpenAI's Operator) do not care about the AX tree. They tokenize a captured frame and predict a click. On Slack and Discord, where the AX tree is thin, that is a tie or a win for the screenshot model. On Mail, Finder, Settings, and most AppKit / SwiftUI apps, where the AX tree is dense, the AX agent is faster, cheaper, deterministic, and immune to layout reflow. The right answer on macOS today is hybrid: AX-first for apps that expose a usable tree, vision fallback for the Electron and canvas-rendered apps, and an explicit disambiguation step so the agent knows which path it is on at any moment. The boundary work in confirmAccessibilityBrokenViaFinder is what makes the hybrid possible without nagging the user.