PieFedMy Accessibility Stack and the future on Wayland
exucross-posted from: https://feditown.com/post/3071906
Edit: To clarify, this is not my personal blog. It’s just intended to raise awareness and spread it around here as well. I just don’t believe in editorializing titles
Share on Mastodon
Share on Reddit
Share on WhatsApp19 Comments
Comments from other communities
The only touching point I ever had with accessability Hardware was a steelseries sentry (tobii eyetracker rebranded) out of novelty for my stream back then.
This was a very interesting read, stay strong mate! <3
Just to clarify, I didn’t write this blog post. It’s just intended to raise awareness and spread it around here as well. I just don’t believe in editorializing titles
kugmo
mrbnnot a single one of those compositors implement the entire API surface you need.
Aegis has requested that those of us who wish to not see Talon on Linux die out do the following:
- Do not, for any reason, discuss Wayland support with him;
- As a community, gather together, and successfully implement the entire API surface needed for Talon on GNOME, KDE, and wlroots,
At which point a new Wayland backend will be considered for Talon.
I agree that it’s not up to Talon to implement the missing APIs in the compositors. However, I think the dev is doing a disservice to the users of Talon by not adding wayland support (ie making the calls to the APIs Talon needs to function). If Talon used those wayland protocols, users could point to the software and say it’s “not working on compositor because the compositor is missing wayland protocols”.
IMO its a much easier sell to the compositor people when they know a useful piece of software is actively trying to target those APIs.
That being said, I sure hope the situation improves. The state of accessibility on wayland is pitiful.
I don’t know how you add a call to an API that doesn’t exist
as a solo dev, I honestly feel for him. It’s just too much work to actually even think about when you have other environments to support
I don’t know how you add a call to an API that doesn’t exist
As far as I know, these messages are passed to the portal using dbus. So the app could just fire the correct dbus message with correct parameters (you can find the correct values in the Wayland specs). The portal, used by the compositor, then takes the message and runs the requested action or returns something like not implemented or unknown method.
The trickier part is testing when no portal supports the API calls.
But yeah, interoperability between systems can be a pain in the ass.
The process is analogous to sending an http request. Your app sets up the httpclient and points it to a URI and after sending the request you get back either the content with 200 status or 404. If you get 404 you can show the user a message like “this website doesnt support feature xyz”
ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL_1FAEFB6177B4672DEE07F9D3AFC62588CCD2631EDCF22E8CCC1FB35B501C9C86
Yeah, even from a non-accessibility standpoint, they’re severely lacking. Text replacement shortcuts, mouse automation, it feels like a nightmare when you long for the control Windows users still have over their systems.
I’ve been using the Speed of Sound appimage for voice input, but it’s just basic whisper to text on a global hotkey. I can get mouse control via python but only relative positioning. I tried to hack in some dead reckoning going to a bounding corner and coming back out but it’s super cagey with accelleration which i’m not willing to turn off.
You’re not an edge case; there are lots of us out there who would use a proper input api.
Just to clarify, I didn’t write this blog post. It’s just intended to raise awareness and spread it around here as well. I just don’t believe in editorializing titles :)
You can avoid the ambiguity by posting it as “Author: title of post”. This way we can see you attribute the post to someone else.
It’s not so bad like the article author describes, there is work being done to address the input issue e.g.
libeiand wayland protocols. (also N.Graham answer that says that it should be done on wayland level if they require universal solution is right if a bit unkind)And how many years will it take before this reaches a usable state, when people need (not just want) it now?
First, it is usable just not the way Talon requires (and its developer doesn’t want to support wayland). Second people can use LTS distributions that will ship X11 for many years, and by that time it will either be good enough or won’t.
xdotool and kin didn’t work on Wayland for me.
same, these are surfaced in python, but it’s barely usable
device = uinput.Device([
uinput.BTN_LEFT,
uinput.BTN_RIGHT,
uinput.REL_X,
uinput.REL_Y,
])
device.emit(uinput.REL_X, 0)
device.emit(uinput.REL_Y, 0)
device.emit(uinput.BTN_LEFT, 1)
device.emit(uinput.REL_X, -100)
device.emit(uinput.REL_Y, -100)
Yeah I wrote something using a lower level interface. Like at the usb layer or some shit, I forget. I gave that up and went back to X.
There is wdotool, it’s not complete re-implementation yet, but it works.
I agree that Wayland has massive accessibility deficits but it certainly doesn’t help if the talonvoice developer shuts down attempts to improve the situation with "Wayland is not supported.".
I agree, but this seems like a matter of poor communication. It doesn’t sound like the Talon dev knows that actual members of the KDE team are earnestly interested in making Talon work with their Wayland compositor. It sounds like they assumed it’s just another user asking for Wayland support without any way of helping to make it happen.
The Talon and KDE devs should open a direct line of communication to actually get this going.
Every DE apart from GNOME, KDE Plasma, Cosmic and a couple of obscure tiling WMs is still based entirely on X11. We are still a very long distance away from abandoning X11.