Linux accessibility (AT-SPI) backend for the Skia.X11 head — working PoC + offer to contribute

[egarim]

Target: Uno.UI.Runtime.Skia.X11

Summary

6.6 brought Skia accessibility to Windows, macOS and WebAssembly, "with further
target platform support to come." I'd like to help bring the Linux / X11
one, and I've built a working proof-of-concept to de-risk it — not just the
read path: an AT-SPI client can read and drive a Uno app entirely over the
accessibility bus.

On Linux the Skia head renders to X11 but publishes no AT-SPI tree, so a Uno
app is invisible to Orca and to AT-SPI-based automation. Skia.X11 already has a
DBus/ layer but no Accessibility/ provider — that's the gap.

What the PoC proves

A standalone AT-SPI server, written on Tmds.DBus.Protocol (the same D-Bus stack
the head already uses), verified headless in a Docker container (Xvfb + dbus +
at-spi2-core). It walks a Uno app's automation peers and serves them over the
accessibility bus:

Read path

• Registers on the AT-SPI desktop via org.a11y.atspi.Socket.Embed
• Serves org.a11y.atspi.Accessible + Component per control
• ComboBox items exposed as selectable children (they live in a popup, outside
  the visual tree)

Write path — the part that makes it useful to more than screen readers

• Action — press / toggle / expand or collapse / select, dispatched to the UI
  thread and executed through the control's automation provider
  (IInvokeProvider / IToggleProvider / IExpandCollapseProvider /
  ISelectionItemProvider)
• Value — slider read + clamped write through IRangeValueProvider
• EditableText + a minimal Text read side — type into an entry through
  IValueProvider, read it back over the bus
• Selection — enumerate and select combo items

Live events

• StateChanged (focused, checked, expanded),
  PropertyChange (accessible-value for slider/text), SelectionChanged

Every claim above is a headless proof in the repo, e.g.:

[check box] 'Enable notifications'  CHECKED before = False
  → Action.do_action(0) → CHECKED after = True
[slider] 'Volume'  set_current_value(80.0) → read back 80.0
[entry] 'Search box'  set_text_contents(...) → read back 'hello from the bus'
[combo box] 'Theme selector'  Selection.select_child(1) → 'Dark' → is_child_selected(1) = True

Two pieces of hardening worth mentioning:

• Cross-toolkit parity check: the same client + proofs run against a twin
  app built on a toolkit that already ships a native AT-SPI backend on Linux;
  4/4 behavioral proofs pass on both, and the per-control dump (role /
  interfaces / actions / states) is identical for all six control types. The
  bridge behaves like a native backend from a client's point of view, not like
  an approximation.
• Role-mapping regression test: libatspi derives the role name from
  the numeric role id, not from GetRoleName, so the ids must be the real
  AtspiRole enum values or everything comes back mislabeled. A small xUnit
  suite (no display needed) locks the mapping.

The code is already factored along the line a real backend needs: a
platform-neutral PeerTree (peer-tree walk, live state, write-path through
the automation providers, change notifications) and a separate AT-SPI/D-Bus
transport that consumes it. Binding into Uno means swapping the tree's source,
not rewriting the protocol half.

Repo (MIT, full container repro): https://github.com/egarim/uno-atspi-bridge
Write-up: https://jocheojeda.com/2026/08/23/uno-linux-accessibility-backend/

What this is NOT (yet)

Deliberately open, and the reason this is a discussion rather than a PR:

• Static tree. It snapshots the peer tree at startup; no children-changed
  events for runtime mutations yet. (Live state is tracked; live structure
  is not.)
• It walks the public FrameworkElementAutomationPeer API from app code —
  a real backend should hook Uno's internal automation abstraction, the
  same seam the macOS/WASM providers use.
• Text is minimal (GetText + CharacterCount) — no caret, selection
  ranges, or attribute runs.
• Non-actionable internals aren't filtered (scrollbar repeat-buttons leak).

The ask

1. Is a Linux AT-SPI backend in scope / wanted for a coming release? Is anyone
   already on it?
2. Which internal seam should it bind to — pointers to where the macOS/WASM
   providers attach to the automation abstraction and to the X11 window host
   lifecycle?
3. If it's welcome, I'll port the PoC into Uno.UI.Runtime.Skia.X11
   (Accessibility/), reuse the existing DBus/ layer, and bring the tests.
   Happy to split it into reviewable PRs — suggested split: read path +
   registration first, then live events, then the write path
   (Action/Value/EditableText/Selection), then dynamic tree updates.

Glad to connect on LinkedIn or X if that's faster.

[MartinZikmund]

Hi @egarim, happy to see you here!

1. Yes, it is definitely in scope, but nobody has started on it yet
2. The majority of the implementation will likely be scoped in the Uno.UI.Runtime.Skia.MacOS project
3. That sounds great! Feel free to do multiple PRs so that we can review in smaller chunks and provide feedback more efficiently. Our @ramezgerges will probably be the best point of contact for PR reviews, as he is the main developer of the X11 backend

Thank you very much for working on this!

[egarim]

Quick update — I've opened the PR for this: #24381 (tracking issue #24380).

It ended up going a bit further than just the read path, so it lands the X11 head at behavioral parity with the macOS/WASM heads in one branch:

• Read path + registration — Socket.Embed, serving Accessible + Component, role map against atspi-constants.h, host wiring mirroring the macOS seam (IAccessibilityOwner / AccessibilityRouter).
• Full interface set — Action, Value, Text, EditableText, Selection.
• Live events — state-changed / property-change / selection-changed / children-changed, driven off the shared SkiaAccessibilityBase Update* / SetNativeFocus hooks, plus focus tracking.
• Write path — driving the real control through its automation provider on the UI thread (invoke / toggle / set-value / set-text / select).
• Absolute screen coordinates in GetExtents.

Verified headless (Xvfb + dbus + at-spi2-core): an external AT-SPI client reads the tree and drives controls over the bus — EditableText.SetTextContents → read back through Text, Value.SetCurrentValue → read back, checkbox toggle via Action.DoAction, with the live state/property signals observed on the bus, and extents shifting correctly when the window is moved.

The commits are already split along the read-path → live-events/write-path line, so if you'd rather review (or merge) it as smaller PRs, I'm happy to break it up — just say the word. @MartinZikmund @ramezgerges

Two Tmds.DBus.Protocol 0.92 gotchas worth flagging for whoever reviews: MessageWriter is a ref struct (writing the body through a by-value helper silently drops it), and 0.92 tears the connection down on an unhandled incoming call — both are handled in the PR.