#21 - AuraFrame exposes no AT-SPI accessibility tree — controls invisible to screen readers and to automation - Mark/kimi_agent_local_ai_image_enhancer - cyguin git: Adlerian Hierarchical Self-Actualization Syllogism

Mark commented

2026-08-16 22:07:20 +00:00

Owner

Summary

AuraFrame (PyQt6 desktop app) exposes no accessibility tree to AT-SPI — the entire widget set is invisible to assistive technology and to accessibility-driven automation. This is both a human accessibility defect (AuraFrame is unreadable by screen readers) and a functional gap for tooling (the computer-use automation lane cannot identify controls by name/role and falls back to fragile pixel-coordinate clicking).

Evidence (verified 2026-08-16 on blackhole, X11/Cinnamon)

Empty AT-SPI tree. get_app_state on the AuraFrame window returns accessibility_tree_raw_count: 1 — a bare application root node ("python3.12") with no children (no Open/Save/AI Upscale buttons, no model dropdown, no controls).
Not an environment failure. AT-SPI infra is healthy (at-spi-bus-launcher, accessibility dbus daemon, at-spi2-registryd all running). A GTK file-chooser dialog launched from AuraFrame did expose real accessibility nodes (click tool found a "check box 'Open'") — proving AT-SPI works; the defect is specific to AuraFrame/Qt.
Not fixed by the standard Qt6 trigger. Relaunching with QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 still yielded raw_count: 1. The installed PyQt6 runtime ships no accessibility bridge plugin: no libqspi, no *accessible*, and plugins/generic only contains evdev/evdevtouch input plugins.
Root-cause direction. PyQt6 runtime at ~/.local/lib/python3.12/site-packages/PyQt6/Qt6 (platform theme libqgtk3.so) is missing the Qt accessibility/AT-SPI bridge linkage, so the widget tree is never registered with the running AT-SPI bus.

Why it matters

Human: AuraFrame is effectively unusable by a screen-reader user — every control is an unlabeled blob.
Tooling: The computer-use automation lane is forced to drive AuraFrame by pixel coordinates (we had to guess (71,59) to click "Open"). With a proper AT-SPI tree it could click by name/role deterministically.

Repro

cd ~/Projects/kimi_agent_local_ai_image_enhancer
DISPLAY=:0 ./run.sh     # GUI launches, window 1280x800 "AuraFrame — AI Image Enhancement"
# query AT-SPI: accessibility_tree_raw_count == 1 (bare root, no widget nodes)

Suggested fix direction

Ensure the PyQt6/Qt6 accessibility bridge is present and loaded (install/ship the Qt accessibility plugin; verify libqspi/libqtaccessible* is on the runtime path) so the Qt widget tree registers with AT-SPI. Verify by re-querying AT-SPI and confirming the tree contains the app's controls with real roles/names, and that a coordinate-free click(name="Open") works.

One root cause (Qt bridge not exposing the widget tree) — one issue serving both outcomes.

## Summary AuraFrame (PyQt6 desktop app) exposes **no accessibility tree to AT-SPI** — the entire widget set is invisible to assistive technology and to accessibility-driven automation. This is both a **human accessibility defect** (AuraFrame is unreadable by screen readers) and a **functional gap for tooling** (the computer-use automation lane cannot identify controls by name/role and falls back to fragile pixel-coordinate clicking). ## Evidence (verified 2026-08-16 on blackhole, X11/Cinnamon) 1. **Empty AT-SPI tree.** `get_app_state` on the AuraFrame window returns `accessibility_tree_raw_count: 1` — a bare application root node ("python3.12") with **no children** (no Open/Save/AI Upscale buttons, no model dropdown, no controls). 2. **Not an environment failure.** AT-SPI infra is healthy (`at-spi-bus-launcher`, accessibility dbus daemon, `at-spi2-registryd` all running). A GTK file-chooser dialog launched from AuraFrame **did** expose real accessibility nodes (click tool found a "check box 'Open'") — proving AT-SPI works; the defect is specific to AuraFrame/Qt. 3. **Not fixed by the standard Qt6 trigger.** Relaunching with `QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1` still yielded `raw_count: 1`. The installed PyQt6 runtime ships **no accessibility bridge plugin**: no `libqspi`, no `*accessible*`, and `plugins/generic` only contains evdev/evdevtouch input plugins. 4. **Root-cause direction.** PyQt6 runtime at `~/.local/lib/python3.12/site-packages/PyQt6/Qt6` (platform theme `libqgtk3.so`) is missing the Qt accessibility/AT-SPI bridge linkage, so the widget tree is never registered with the running AT-SPI bus. ## Why it matters - **Human:** AuraFrame is effectively unusable by a screen-reader user — every control is an unlabeled blob. - **Tooling:** The computer-use automation lane is forced to drive AuraFrame by pixel coordinates (we had to guess (71,59) to click "Open"). With a proper AT-SPI tree it could click by `name`/`role` deterministically. ## Repro ``` cd ~/Projects/kimi_agent_local_ai_image_enhancer DISPLAY=:0 ./run.sh # GUI launches, window 1280x800 "AuraFrame — AI Image Enhancement" # query AT-SPI: accessibility_tree_raw_count == 1 (bare root, no widget nodes) ``` ## Suggested fix direction Ensure the PyQt6/Qt6 accessibility bridge is present and loaded (install/ship the Qt accessibility plugin; verify `libqspi`/`libqtaccessible*` is on the runtime path) so the Qt widget tree registers with AT-SPI. Verify by re-querying AT-SPI and confirming the tree contains the app's controls with real roles/names, and that a coordinate-free `click(name="Open")` works. One root cause (Qt bridge not exposing the widget tree) — one issue serving both outcomes.

Mark

2026-08-16 22:07:20 +00:00

closed this issue
added the
bug
label

Mark reopened this issue

2026-08-19 22:23:42 +00:00

Mark commented

2026-08-19 22:23:42 +00:00

Author

Owner

Reopened by kilo-gsd-runner: prior kilo-gsd run (2026-08-16) closed this issue as a false-positive — it exited 0 with "No changes to push" and verified against the wrong (#20) plan, so no fix ever landed and no commit references #21. Reopening to allow a proper dispatch; the new run will write an issue-specific plan.

Mark

2026-08-19 22:24:30 +00:00