Accessibility tree limits beyond the browser: four boundaries you cross at once.

Inside Chrome the accessibility tree is a single in-process structure derived from the live DOM and ARIA. You query it with one API, addressing is by selector or role, and access is implicit because your script runs inside the same page. Step outside the browser and four things change at once. The API splits into NSAccessibility on macOS, UI Automation on Windows, and AT-SPI on Linux, with no shared interface. The trust model splits too: you need a system-wide accessibility permission granted by the user in System Settings, not zero-config in-page access. Addressing becomes a process plus window plus element triple, not a URL plus selector. And the error codes overload meanings the browser never had to express, like one OS error returned for both 'permission revoked' and 'this app never implemented AX'. Each boundary on its own is a small change. Together they are why a browser-AX harness does not port to the desktop with a tweak.

Each OS predates the W3C ARIA spec and grew its own assistive-tech layer for screen readers in the 90s and 00s. macOS has NSAccessibility, exposed in C as the AXUIElement family declared in the AppKit-adjacent ApplicationServices framework. Windows has Microsoft UI Automation, an evolution of Microsoft Active Accessibility (MSAA). Linux has AT-SPI, the GNOME assistive technology service interface. They were designed for VoiceOver, Narrator, and Orca respectively. Browser AX trees are layered on top of these per-platform APIs: Chromium maps the DOM and ARIA to the native AX layer of whatever OS it runs on, which is documented in Chromium's accessibility overview. So in a sense the browser AX tree you query in DevTools is already a translation of the platform API. Outside the browser there is no translation, you call the platform API directly.

In the browser, your code can read the AX tree of the page it is in for free. There is no permission to grant. On the desktop, an external process that wants to read another process's AX tree needs to be granted accessibility access by the user. On macOS this is the System Settings > Privacy & Security > Accessibility toggle, gated by TCC. On Windows it is UI Automation client privileges, generally available without a special grant but elevated processes have an asymmetric view. On Linux it is at-spi-bus access plus DBus session policy. The macOS case is the most user-visible: every desktop AX agent on a Mac has to walk a user through a settings toggle on first run. Worse, the toggle has a cache that goes stale on macOS 26 after an app re-sign or update, which means an agent that does not probe around AXIsProcessTrusted will report 'broken' to a user who already granted the permission.

In the browser, an element is addressed by a CSS selector, an ARIA role plus name, or an XPath rooted at the document. The document is one. Outside the browser, you address by process identifier first, then by window inside that process, then by element inside that window. On macOS that is AXUIElementCreateApplication(pid) to get a per-app root, then kAXFocusedWindowAttribute (or kAXWindowsAttribute) to enumerate windows, then a recursive walk of kAXChildrenAttribute to find a leaf. There is no single root for 'the desktop'. There is no document.querySelector. An agent has to discover the process graph, which is also moving in real time as the user opens apps. The output you give the model is usually a flattened text dump scoped to one window, not a query result.

The interesting one is AXError.cannotComplete, which is what AXUIElementCopyAttributeValue returns when the call cannot be answered. It is overloaded: returned for revoked accessibility permission, returned for apps that never implemented NSAccessibility (most Qt builds, Tk apps like PyMOL), and returned for a target process that is alive but not responding. The browser never had to express any of these because the browser's AX tree is in-process and either populated or not. A naive desktop agent that maps cannotComplete to 'permission broken' will nag the user every time they open a Qt app. The fix is to disambiguate against a control. AXError.apiDisabled is the unambiguous 'system AX is off' code. AXError.notImplemented and AXError.attributeUnsupported mean the element exists but the attribute does not, which is fine to fall back from.

Probe a known-good control. The Fazm agent, when it gets AXError.cannotComplete from a frontmost app, runs the same AXUIElementCopyAttributeValue against com.apple.finder before doing anything else. Finder always implements NSAccessibility and is always running on a Mac. If Finder fails too, the permission is genuinely stuck and the agent surfaces a Quit and Reopen dialog. If Finder succeeds, the original failure was app-specific, the permission is fine, and the agent logs the suspect app as AX-incompatible and falls back to vision. This pattern is at AppState.swift line 468 in github.com/m13v/fazm under the function name confirmAccessibilityBrokenViaFinder. There is no equivalent in the browser because the browser has one document and one process, so 'control element' is a category that does not exist.

Mostly. Roles map across cleanly: a button in ARIA is AXButton on macOS and ControlType.Button in UI Automation. Names map: aria-label becomes AXTitle / AXValue on macOS and Name on UIA. Hierarchy maps: a tree walk is a tree walk. What does not map is the assumption that the structure is dense. Browser AX trees are dense because the DOM is dense. Desktop AX trees can be very sparse, especially in Electron and Qt apps where the renderer never built the nodes. The other thing that does not map is the assumption that 'the tree is up to date with what is on screen'. On the desktop, an animation, a modal that just opened, or a window minimization can leave the AX tree out of sync for hundreds of milliseconds. A productive working assumption: take a fresh tree dump after every action, do not cache.

If you run the Fazm agent locally, every time it calls a desktop tool it writes a file to /tmp/macos-use/<timestamp>_<tool>.txt that contains the exact AX tree dump the LLM received as context. Open one in any editor. Each line is one element, format is [AXRole (subrole)] "title" x:N y:N w:W h:H, and the file starts with a header like '# Fazm Dev — 146 elements (0.19s)' showing the element count and traversal time. That is ground truth: if a click landed, the element was in the .txt. If the action failed, you can grep the file to find out whether the model was guessing from a stale tree or whether the element was simply absent (AX-thin app, screenshot fallback territory).

Not in general. On the apps where the AX tree is well-implemented, which on macOS is most native AppKit and SwiftUI apps plus the Apple-shipped suite, an AX agent is faster, cheaper, and more deterministic than a screenshot agent. No frame, no model pass to tokenize pixels into elements, no coordinate prediction. The honest answer is hybrid: AX-first for apps that expose a usable tree, vision fallback for the apps where AX is thin or absent. The boundary work is what makes hybrid possible, because without disambiguating cannotComplete you cannot tell whether to fall back or to ask the user to fix a permission.

Windows UI Automation is closer to a single coherent API than macOS or Linux, and most Win32, WinUI, and WPF apps participate. WinForms and Electron apps on Windows have similar gaps to their macOS counterparts. The big Windows-specific quirk is the elevation asymmetry: an unelevated UIA client cannot read elements in elevated processes. Linux AT-SPI is the most fragmented surface, because it works only when the toolkit (GTK, Qt with the AT-SPI bridge plug-in) opts in. On both OSes the four boundaries crossed are the same conceptually: a different API, a permission or capability check, a process-rooted addressing model, and ambiguous error codes. The function names change. The shape does not.