GTK: screen reader accessibility (Orca / AT-SPI) for the terminal surface

[alex19EP]

What do you want to change?

I want to start upstreaming my work on Ghostty's GTK apprt accessibility for blind users.

I added GtkAccessibleText/Hypertext support to Ghostty's surface so Orca could read what is displayed in the terminal.

What works now: text reading, flat review (line/word nav), typing echo and command output, focus changes between surfaces, caret and selection, OSC 8 + regex links, text attributes, braille.
So the whole terminal surface is usable for blind users. I tried not to touch menus/other chrome yet, since I fear breaking something for sighted users.
One thing I changed is focus and key handling in src/apprt/gtk/ui/1.2/surface.blp. That was done because Orca flat review needs the focus to be on an object with text, and the GLArea where focus was before my change has a panel role, which Orca doesn't like.
I haven't encountered any side effects of this change, but since I'm not using a mouse, for example, I will certainly need someone sighted to check this.

I commented at #2351 when I started this work.

I now have a working implementation at https://github.com/alex19EP/ghostty/tree/gtk-accessibility-poc, which I have been daily driving myself for 4 months, and I also invited Orca users to test it.
You can look at the invitation and testing feedback at https://www.freelists.org/post/orca/Testers-wanted-Orca-support-for-the-Ghostty-terminal-emulator

I also tried to extensively cover the new code with tests: I have Zig unit tests and also a test harness which drives AT-SPI, similar to the macOS one. The AT-SPI harness is excluded from CI.

I also found and fixed three bugs in Orca terminal reading support itself along the way; all three are merged upstream.

If you are OK with this, I would upstream it in small PRs, e.g.:

• Basic text exposure (GtkAccessibleText — reading the viewport, change events, focus)
• Links (GtkAccessibleHypertext, OSC 8 and regex)
• Caret and selection

Each PR would contain its own tests. The AT-SPI harness is Python + pytest — would you want it in-tree, or should I keep it on my branch?
Then I'll rebase my PoC branch as each one lands, and will continue to daily drive it and tell users to test it.

AI usage disclosure

Claude Code heavily assisted me with the implementation. Architecture and testing were mine. I also read the Zig code and corrected some incorrect AI assumptions, such as emitting text change events on every frame even when nothing changed, and feeding bytes instead of codepoints to AT-SPI.

Why do you want to make this change?

Before my implementation, the only accessible terminals for blind Linux users were VTE-based ones such as GNOME Terminal. VTE's a11y implementation has bugs that have gone unfixed for a long time, and it is rather slow.

As a blind Linux user who uses Orca and a braille display, and relies on a terminal for daily work, I started looking at Ghostty, and I liked its performance and feature list. The only problem was the total inaccessibility.

I looked at requests to add a11y to Ghostty and found #2351, where Mitchell said Linux could be indefinitely delayed until it was clear what improvements were possible — and this branch is an answer to that question.

I acknowledge that:

• I have read the Contributing Guide and understand the contribution process.
• I have read and agree to follow the AI Usage Policy.
• I wrote this vouch request myself, in my own voice, without AI generating it.

[jcollie]

!vouch