Major distros are soon switching to versions of desktop environments that use Wayland instead of X11. This is a bad state of affairs for accessibility.
This page's posts are visible only to users who are logged in.
You must log in to comment.
in reply to @rykarn's post:
i think in 5 or 10 years when the dust starts to settle, we're going to see one wayland compositor stack win: wlroots. I don't see a way that multiple flavours of wayland survives in the long term, and wlroots has the most support in terms of 1. number of compositors, 2. number of ancillary tools, and 3. breadth of protocols for things like accessibility and more (no clue what the state of that kind of thing is currently)
i'm probably going to stick with xorg as long as i can too.
finding this while trying to figure out if talon has wayland support, thanks for the writeup (and sympathies)
In case you are interested, I've edited the post to include a link to the repo outlining the wayland a11y issues: https://github.com/splondike/wayland-accessibility-notes/tree/main
oh bloody hell, each window manager needs to impliment xdg-desktop-portal? ughhhh
I hate how every big distro seems to charge forward on changing stacks like this when Wayland breaks most accessibility tools like, i don't need the desktop to look fancier that bad. Get this shit ready for prime time FIRST and then switch.
Agreed, and the tragedy of Wayland is that none of the problems you're experiencing were necessary to create a replacement to X11. These problems were designed in, deliberately, by zealots. They want to be as *un-*X11 as possible regardless of the consequences.
Note, the following should be taken with a huge grain of salt due to my very superficial understanding of wayland and the needs of Talon Voice and a11y interfaces in general:
I have not kept up much at all with developments save for what people sometimes post in the Linux channel in the Talon Voice slack channel. One development is Newton. Skimming it gives me the impression that it is focused on GTK and AT-SPI which is a way for a11y tools to interact with GUIs of individual apps. This is good, but Talon also needs access to the entire desktop state (what windows are present, interacting with the DE itself, emulating keyboard and mouse). Some of these things are brought up in the blog post also so maybe some of this work would lead to features that Talon needs. However, this is directly implemented in the Gnome compositor at the moment, it is not yet promoted to official wayland protocols or dbus interfaces that would allow a compositor-agnostic approach to a11y.
For reference, here are the requirements which I posted in another comment where the needs of Talon are outlined.
Based on what I can gather from the Talon developer, it is unlikely he will implement wayland support unless it can be done via official protocols and interfaces. He will not want to implement it for one specific compositor. I am well aware that he is not a fan of having to support Linux in general, it being the smallest user segment of Talon yet the biggest support burden, due to it being such a moving target (different display servers, certain DEs dropping system tray support, just so many different combinations of distros and window managers/DEs).