I'm willing to pay up to $10,000 (USD), to whomever I need to pay, to solve the #GNOME AT keyboard input handling problem once and for all. Currently, toolkits implementing AT-SPI have to pass all keyboard events to the AT-SPI registry, then wait for a response on whether the event should be processed as usual. No other platform does something like this, and this unique platform-specific requirement is a major complication for #AccessKit. I want to get this fixed. #accessibility

reshared this

in reply to Matt Campbell
Efforts to solve this have been in limbo for a while. The GTK team already refused to implement the legacy solution in GTK 4. So AT-SPI has a solution that kind of works when using X11. And there's a draft PR to solve the problem for GNOME Shell on Wayland, but it's only half done. And because the X11 solution introduces its own problems, Orca only uses it for GTK 4 apps. So I'm willing to invest in getting this solved completely.
in reply to Matt Campbell
To be clear, I'm not criticizing the GNOME developers or anyone else. They're all doing the best they can with the limited time and resources they have. But because this problem is affecting my project, I want to do what I can to help solve it.
in reply to Matt Campbell
I could, of course, jump into the code myself. But (1) I don't currently have time to spend significant time on this, and (2) I don't feel that I'm expert enough in AT-SPI, Orca, Mutter, X, Wayland, D-Bus, etc. to implement a solution at all relevant layers of the stack that will be accepted upstream. So I want to make it worthwhile for the experts to work on this.
in reply to Tristan Partin
@tristan957 @ebassi Not yet, only because I figured the owners of the relevant components (Mutter, at-spi2-core, maybe even Xorg) don't actually work for the GNOME Foundation. So I didn't really know whom to talk to.
in reply to Matt Campbell
@tristan957 The main person to talk to would be Carlos Garnacho, who works on the X11 and Wayland input stack in both GTK and GNOME Shell. The Foundation does not employ any developer, at the moment, so it's not an issue of funding, and more an issue of having people actively working on the stack.
in reply to Emmanuele Bassi
@tristan957 In February, before FOSDEM, we're going to hold a GTK hackfest, and accessibility is on the agenda; I'll make sure to talk to Carlos about this issue. The main problem is not really going to be implementing an interface in GNOME Shell and GTK, though, but working on Orca and other ATs; sadly, we have not had much luck trying to involve AT maintainers, because there aren't many contributors on that side.
in reply to Emmanuele Bassi
@ebassi @tristan957 Orca is already conditionally using a newer method of keyboard handling in at-spi2-core in GTK 4 apps. So my understanding is that there are two blockers: the X11 solution introduces its own problem (temporarily deactivating and reactivating the focused window), and the Wayland solution (a PR in Mutter) is incomplete.
in reply to Matt Campbell
@ebassi I've never contributed to Orca before. However, I have a strong background in screen reader development. I used to work on the Narrator team at Microsoft (my non-compete is expired), and I wrote another Windows screen reader before that.
in reply to Emmanuele Bassi
@ebassi Mike has already been in contact with me via email. He says that solving the Orca keyboard handling problem is mostly a matter of tying up loose ends, and he has already started on that again. So my offer of money may have been premature. The offer still stands though.
in reply to Matt Campbell

No worries; I'll try to get @federicomena and Mike and see what's still missing in at-spi2-core and mutter; maybe we need something entirely different, like a Wayland protocol similar to the wayland text input one.

At this point, X11 is mainly an exotic legacy platform, so it's not really a consideration in new designs.

in reply to Matt Campbell
@tristan957 Solving this issue in the compositor is possible, but of course it requires fixes in every compositor. Anyway, I've raised this issue with the people involved with GTK and GNOME Shell, so we can talk about possible solutions.