xa11y 0.8.2 brings Rust-powered desktop automation via accessibility trees

xa11y 0.8.2 landed as more than a routine crate bump. It pushed Rust into a new kind of developer primitive: a Playwright-style way to drive native desktop apps on macOS, Windows, and Linux by talking to accessibility trees instead of chasing screenshots.

That shift matters because accessibility state is usually more stable than pixels. When an app rerenders, changes theme, or redraws a window, image matching can wobble. xa11y takes a different path, using the semantic structure exposed by the operating system to find controls and act on them. The result is a cleaner fit for end-to-end desktop testing, computer-use agents, MCP tools, and assistive software.

The 0.8.2 package also came with practical reach across platforms. PyPI lists pre-built wheels for Linux, macOS, and Windows, along with Python 3.9+ support. On macOS, users need Accessibility permission, and on macOS 26 and later they also need Screen & System Audio Recording permission to read window content. Linux depends on AT-SPI2. Windows, by contrast, needs no special permissions.

The API surface is built for the kind of work desktop automation actually needs. xa11y supports CSS-like selectors over accessibility trees, including role selectors, attribute filters, child combinators, and nth-match selection. It can press controls, focus and blur them, toggle switches, expand and collapse sections, select items, set values, type text, increment and decrement fields, and open menus. That puts it squarely in the territory of serious UI automation, not just inspection tooling.

The codebase backs that ambition with a Rust-first layout. The repository is split into shared core code and platform-specific crates for Windows, macOS, and Linux, plus bindings for Python and JavaScript. It uses COM, Core Foundation, and D-Bus through Rust wrappers, which keeps the platform glue isolated while still exposing one API to callers. GitHub showed 294 commits in view, along with recent work on unified developer workflow, bindings parity, CI coverage, Linux AT-SPI improvements, macOS setup automation, and screenshot support.

The rough edges are still visible, especially on Linux. Recent canary testing found that Electron apps such as VS Code and Cursor exposed only a top-level window element through AT-SPI2, while native GTK apps worked correctly. That is the real test for a project like xa11y: whether it can survive the uneven state of accessibility trees across desktop stacks and still become the layer teams reach for when browser automation is not enough.