It's very weird to say, but I feel like I'll eventually be dropping Linux and moving to Windows, and it won't be for videogames.
There are some minor issues with Wayland but most of it works.
I don't know what talon is doing as it seems proprietary, but the issue might be there.
Here is a bit of a discussion though on this topic:
- a summary of the situation: https://github.com/splondike/wayland-accessibility-notes/blo...
- talon-required features and their current compatibility: https://github.com/splondike/wayland-accessibility-notes/blo...
Basically people complaining about needing to do work to modernize.
All the things will eventually be just fine. X11 is a walking zombie.
Yes, users are very understandably miffed that things which were working are suddenly broken and somebody now has to fix it in order to return to the status quo.
> things will eventually be just fine
Wayland is 15 years old. At this rate it will be due for replacement before it's feature complete.
You are misunderstanding. You can continue to keep using applications in X11-mode for as long as those applications maintain that code path. But many of the niceties Wayland provides, X11 won't get because it is virtually unmaintained.
Or said another way, X11 is already broken and getting slightly more broken every day.
And before you get angry at X11 going unmaintained, would you have expected Apple to support Carbon ad-infinitum?
Look at the backwards-compatibility and new-framework-adoption-rate woes Windows has to deal with because Win32 exists and devs are lazy / expensive.
X11 is a complete dead end. All applications need to eventually update. Put pressure on app developers to get to it...
btw, I already said something wrong, because, which wayland? It's not a thing.
Like, you can complain about missing deep accessibility support in something like Bpswm or Ratpoison, but is that really fair?
I'm guessing accessibility support is/will be pretty good on both Mutter (Gnome) and Kwin (KDE). Wlroots-based probably will be too with the community attention it is getting. Stray beyond that and you'll be on your own.
If X11 was going to be some permanent fixture at least people who rely on it for apps that are abandoned or proprietary or can't/won't be updated would have an alternative they could keep using. But while X11 isn't going away any time soon, it's also very clearly not what we want to be building on or encouraging people to use. When I criticize the state of Wayland, I'm not saying X11 is great. I don't want to be on X11, I want to use Wayland. I want the features that Wayland has.
Where accessibility is concerned, we're at risk of losing a bunch of users if they lose the ability to use applications they rely on during the transition or if there aren't alternatives to help control the applications that don't get updated. This is not something where we can just say, "oh the developers are lazy."
If the stuff doesn't get supported, regardless of whether it's the developers' fault or Wayland's fault, the users can't just deal with it until the ecosystem catches up. Instead, they go to Windows (or more realistically to Mac, my understanding is that Apple is kind of the gold standard if you need accessibility controls).
----
Also add to this that "developers need to modernize" minimizes just how unapproachable a lot of this stuff actually is. I don't have a good grasp of how accessibility works in X11 because the development philosophy there has been for years "let the toolkit handle it" or "don't worry about it, controllers will just do something weird to handle window placement or font sizes on their own."
What are the standards for handling those problems in the future? There probably are standards, and they're probably better than what X11 was doing, but I don't feel confident that I know what they are. And there are X11 apps that are written by developers who aren't professionals and that have even less knowledge than I do about how the Linux desktop actually works. I would challenge anyone to find a good tutorial online written at a level that novice developers can understand that walks through how to make sure that a Wayland app is accessible, what changes need to be made from X11, and what the common problems or pitfalls are that developers might face.
Again, wouldn't necessarily be the biggest problem in the world -- except for the fact that X11 is a dead end and Wayland is the future. And because it's the future, we really, really need to make this stuff work.
The wayland/x11 compatibility shims work and will continue to do so for a long time, for the reasons you are mentioning. Basically both will work on a Wayland system for the foreseeable future - the big change was making Wayland the default which puts the focus there instead of allowing people to mentally push that work off into the future.
Wayland is prime-time, it's shipping as the default for all the big distros. It's here - time to get with it and update your codebase. Like has already been pointed out, Wayland isn't new, and this day has been coming for years. Now app developers will be compelled to finally put in the work.
It's not fair to complain about Wayland when it's some app developers that are not modernizing.
How do they modernize?
Like you point out, Wayland isn't new. So, I would repeat:
> I would challenge anyone to find a good tutorial online written at a level that novice developers can understand that walks through how to make sure that a Wayland app is accessible, what changes need to be made from X11, and what the common problems or pitfalls are that developers might face.
"Need to modernize" is worthless advice without follow-up advice about what needs to be done to modernize. How many developers building apps for Linux even know what the at-spi protocol is?
----
But more to the point:
> It's not fair
I'm not blaming Wayland devs. I like a lot of Wayland's approach to controls and structure, I agree with a lot of the development philosophy. This isn't about what's fair, I'm telling you that because Wayland is the future and because X11 is a dead end, if users with accessibility concerns can't use Wayland and they can't stick with X11 (which will become increasingly difficult for them to do as X11 decays more and more), they will leave the Linux ecosystem entirely because they will not be physically able to use it. It does not matter who's fault that is.
Is it fair? Who cares, it's going to happen regardless if the accessibility situation doesn't improve.
This is just kicking the can back and forth, blaming application developers changes nothing about the situation that people are in. If application developers need to modernize, then the question becomes "how do we make that easier for them to do and how do we encourage more of them to do it?" Because clearly the current approach of calling them lazy doesn't seem to be working.
I don't use accessibility features, but I do daily drive a Wayland system (Fedora 39 and 38) and have experienced zero issues. I honestly don't even know what system any given app is trying to use - it all "just works". That is to say I don't believe the sky is falling like some people make it sound.
With that said - the more pressure that is placed on app developers to figure it out, the better. Kicking the can down the road just because XWayland works today is foolish. If you have an app that you rely on that uses X11 exclusively - you should complain to the app developers today so that tomorrow it doesn't stop working.
The entire Linux conversation on accessibility summed up in one sentence.
> If you have an app that you rely on that uses X11 exclusively - you should complain to the app developers today so that tomorrow it doesn't stop working.
And when they say, "we agree, what specifically do we need to do to be accessible under Wayland", what do I tell them?
What cannot be accomplished with ATK/AT-SPI?
It's literally all there... but alas, we love to complain.
Documentation and tutorials. I see X11 devs who aren't even looking at Wayland struggling with this stuff. It is very, very clearly not as easy as you are making it sound.
Nor are you in a position to say that everything works if you don't use accessibility controls. You're very confident that the at-spi protocol is fine for everything given that you are someone who does not rely on the at-spi protocol to use a computer and who does not use it as a daily driver.
I am inclined to say that if users who do rely on accessibility controls on a daily basis are complaining, probably they're not making up their complaints.
Who's fault it is that they're running into issues? Again, it doesn't really matter, the issues persist.
This entire thread started off by someone saying untrue rumors about Wayland and DE's regarding accessibility - so excuse everyone who thinks the complaints are likely misguided.
Again - if something is lacking in Wayland compatibility - now - is the time to ask app developers to update. If for some reason it cannot be done in Wayland, it should be reported to the Wayland project! This is not rocket science...
Right now XWayland works as it should. So provide some specifics or get off the pot...
I'm going to tentatively push back on this, my (very limited) understanding of the at-spi protocol is that it exposes application-specific controls and that it's not relevant to conversations about how to control a DE, and that current DEs do not in fact expose a common shared protocol across all of them for the kinds of controls that Talon needs.
I'm not an expert on this stuff by any means, but from what I can tell, OP is correct and is not spouting untrue rumors. I'd welcome correction in the form of some kind of accessible documentation for integrating with those window managers that uses a universal common protocol for all of them, but getting back to something I've pointed out multiple times above:
> so excuse everyone who thinks the complaints are likely misguided. [...] This is not rocket science...
This kind of response isn't particularly convincing given that I note you still haven't linked over some novice-accessible documentation about how to work with this stuff or test it, likely because that novice-accessible documentation is difficult to find if it exists at all.
I would love some easy ways to verify what at-spi controls, how to integrate with it in different languages, and how different DEs handle exposing it for their own interfaces. The absence of approachable documentation is a big reason why people are confused about Wayland (and about other good projects like Flatpak that get commonly maligned on HN, but that's a longer conversation). The absence of easy, clear information about how all of this stuff works might at least partially explain why application developers aren't quickly modernizing.
If you think that Talon developers are lying about how DEs work, then education efforts using clear, user-and-developer facing documentation about the protocols involved would be a pretty good way of combating FUD.
----
> Right now XWayland works as it should. So provide some specifics or get off the pot...
First, as others have mentioned, XWayland is insufficient for the kinds of needs that Talon has; operations like enumerating windows or handling focus can not (and should not) be handled via XWayland unless you plan to run your entire desktop environment in XWayland.
Secondly, XWayland is not the future. It is also a dead end. I'm glad that it exists for now, it is absolutely critical for early adoption of Wayland and is critical for supporting some apps. But XWayland is not a permanent solution to accessibility problems and it's wild to hear people simultaneously say that X11 is a walking zombie and to tell people that accessibility is fine because if there are any problems with Wayland you can always just tie your applications to a walking zombie.
The goal here is to get rid of X11, or at least that's what I think the goal should be, because I do think that X11 is a walking zombie and I resent the fact that I'm still using it.
----
My concern is not that Wayland can't be accessible or that there aren't ways to make it accessible. My concern is that regardless of whether or not universal protocols exist right now, it doesn't look like they're being used and it doesn't look like Wayland is going to be accessible for a lot of people in reality. And I don't care who's fault that is; it's still the case that calling developers lazy and accusing people who are sharing real accessibility problems that they have right now of spreading "untrue rumors" does not seem to be helping to improve the situation.
This isn't a situation like NVIDIA where there's one specific company we can all shame; if a bunch of disparate developers aren't taking the necessary steps to update their applications, then something is going wrong in the communication process or the steps aren't clear enough, or the incentives aren't aligned.
Again, I would welcome clear and accessible documentation that average developers could use that demonstrates how Talon could be made to work with Wayland and how the concerns its developers have (https://github.com/splondike/wayland-accessibility-notes/blo...) could be handled.
Accessibility is the one thing that xwayland isn't useful for; if my input system can't interact with wayland windows, what's the point?
Honestly, yes.
The iPhone is light years ahead of Android on the accessibility side, and it is the device you are most likely to always carry with you.
If you are using an iPhone, it already makes more sense to purchase a Mac, and from that point on going knee-deep into the Apple ecosystem makes sense in a lot of ways.
Like, you can hook up your smart doorbell to your Apple TV (for HomeKit), and when someone rings the door / motion is detected, Apple's image recognition can tell you on your iPhone who is at the door.
Notice that I never said applications. I'm aware that xwayland is actually quite good these days; the problem is accessibility and automation tools that it can't support.
> would you have expected Apple to support Carbon ad-infinitum?
> Look at the backwards-compatibility and new-framework-adoption-rate woes Windows has to deal with because Win32 exists and devs are lazy / expensive.
Yeah, devs are expensive, which is why backward compatibility is so important. Microsoft, for its many faults, seems to understand that breaking applications every few years and demanding that developers put in time in order to keep things working is poor form, leading to people making comments like
> I’ll also give a shout-out to our friends in the Operating Systems business: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, and so on, for doing such a great job of backwards compatibility on their successful platforms.
- https://medium.com/@steve.yegge/dear-google-cloud-your-depre...
In fact, the rest of that essay is a great commentary on exactly why this kind of thing is bad and why Apple should be derided exactly for this kind of thing.
…
> Wayland is 15 years old.
So, it's not very sudden, then, is it?
So much of what people see as wrong in Wayland is about slow-moving applications and driver vendors refusing to adapt; waiting until their software is actually broken before they do anything. We've had more than a decade knowing full well what is coming. I sympathize that an application you rely on is caught up in that. Nobody wanted that situation. But X11 has had a pretty good life. And unless Talon on Linux is suddenly abandoned, I really doubt those developers are going to keep hitching their wagon to X11. At some point, (probably soon now that distributors are getting serious about it), they will take a look at what's new and they will make it work with Wayland.
With that said, I don't think you have to worry for a while. I doubt apps are ever going to stop working in X11 altogether. You might end up with a different desktop at some point if you're using GNOME or KDE, but that's all.
> And unless Talon on Linux is suddenly abandoned, I really doubt those developers are going to keep hitching their wagon to X11. At some point, (probably soon now that distributors are getting serious about it), they will take a look at what's new and they will make it work with Wayland.
That's assuming that they can make it work with Wayland, which appears rather unlikely since the API surface doesn't exist. As you say, Wayland has had more than a decade but most of that time was spent loudly proclaiming that such functionality was a security problem and had no legitimate usecases so here we are.
> With that said, I don't think you have to worry for a while. I doubt apps are ever going to stop working in X11 altogether.
I certainly hope I can keep using X until Wayland actually reaches feature parity, but I'm already seeing pressure on both sides; waydroid is the first[0] application to outright refuse to support X, while Asahi Linux was loudest about not wanting to support Xorg but they're hardly the only ones. I suspect I'm going to end up with a 3-layer system comprised of cage[1] running xwayland running my real graphical environment with some applications in their own little cage windows. It's a little annoying but as a break-glass option it seems to function with only slightly more papercuts than X11 programs on Xorg:\
[0] Well, first that I've noticed at least.
https://wiki.linuxfoundation.org/accessibility/atk/at-spi/st... exists, but is fairly unapproachable and it's not clear to me as a developer where I would start if I was trying to either build an application that hooked into at-spi or to set up automated tests for at-spi events on my own software.
The common advice is always "use a graphical toolkit", but let's say I'm stepping outside of a toolkit like GTK and I'm building something smaller, or let's say that I want to build a toy screenreader of my own. I've had an awful time trying to find documentation about this stuff.
[1] https://en.trycht.cz/2023/12/15/down-and-down-exploring-the-...
[2] https://gitlab.gnome.org/GNOME/at-spi2-core/-/blob/main/READ...
[3] https://gnome.pages.gitlab.gnome.org/at-spi2-core/devel-docs...
So this is not meant to be dismissive of you, I really do appreciate it, but also wow this is still pretty anemic documentation compared to most other tech fields. I kind of wonder if this is also a chicken-and-egg problem because the way the healthy documentation springs up around projects is enough people use the projects that they run into issues, they start documenting best practices... and in areas like Linux accessibility where (as I understand it) there are often like 10-20 people total working on the technologies behind it at any given time, that community isn't going to exist and we're going to get tutorials that say stuff like:
> Of course, there are much more interfaces to use or implement for specific objects, like the Text interface for text controls, Table interface for tables, etc., but the principles of these interfaces are the same, just a normal DBus programming with all it entails.
So there aren't going to be a ton of people doing interesting things in that field or digging into how stuff works, which means it's not going to have people available to help make the field more approachable.
But again, I do appreciate the resources you did find.
The important bits:
> if you only say "accessibility" you may get the response "but at-spi2 works independent of x11 or wayland" the problem with at-spi2 is that it's opt-in by the application, so some programs just don't show up at all. the coverage of at-spi2 in video games is basically zero, for
and
> [...] wayland's stance on tools like talon is 'no' [...]
I may also need to switch back to windows if X11 support is dropped "too far" before wayland is there in the accessibility aspect.
I'm not a big Wayland fan (quite the opposite truly), but I don't know if this is true: if there's an accessibility protocol made for Wayland you could (in theory) have one accessibility SW accessing many Wayland DE.
So this isn't a Wayland design issue, but it is an implementation issue: given that many DE have reimplemented the Wayland server, there will be less shared code than with X and more bugs to take into account.
Of course given the age of Wayland and that this is still an issue really show the problems with Wayland..
This is the core problem I have with Wayland. There is no "Wayland server", just as there are no window managers. It's _just_ a protocol.
Wayland has conflated those two concepts by making every Wayland compositor have to do both roles. I think most casual users haven't realized this. KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain).
That makes targeting it, whatever "it" actually is, with tools for accessibility all that much harder. That's on top of the Wayland protocol's hostility to things that would make that job easier. We've "secured" the system against use by anyone who doesn't have working eyes or hands. There's no malice there, just the unintended consequence of a system designed by able-bodied people. I'm not even sure X is better in this regard, except that there are solutions like Talon that work there.
There are shared libraries like wlroots that can help with consistency, but it doesn't implement everything and not every compositor is using it. Something like accessibility shouldn't be an extension protocol but a core part of the design.
It is never too late to start improving things.
On the other hand, this means that the ecosystem overall stays fragmented and we get an eternal state of "to do X in Windows do foo, in MacOS do bar, and on desktop Linux see this wiki page discussing your options". And while I suppose there would be value in ex. screenshot tools only needing 3 code paths, it would have been nice to only need 1.
This is something I've been wondering for a long time - how long will it take before someone writes a Wayland-based server that provides an interface for window managers, system trays, and whatever other clients running in other processes, mimicking what X does?
I considered wlroots but the complexity is far higher and Im not in a rush to move to Wayland.
Furthermore it was of vital import for KDE and Gnome to support both X11 and Wayland for years and leverage their large existing codebase. Wlroots would both have to travel back in time like the terminator from 2018/2020 to 2010 and become universally suitable en route.
This is fine. Every windowing system in common use (and a dozen others) took that path. X11 is the odd thing here.
IMHO the actual strategic mistake for Wayland was that they prioritized writing standards over iterating on a working reference implementation that was usable as a daily driver. You shouldn't need an alternative window manager any more than you would need an alternative trackpad firmware. It's supposed to be invisible. Draw the window borders using a plugin/subprocess, because your existing user base demands shallow "customization". Cover the 99% use case, and expose an API for extensions to do stuff like auto-tiling or shader effects. Focus on what users actually need from the applications (like: working screen capture).
X11 - the platform with more window managers and terminal emulators than actual apps. Wayland needn't repeat the same mistakes, but here we are on that trajectory.
> KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain).
Close enough. We have kwin, Mutter, and wlroots (the last one effectively doing what Weston should have done from the start) - three disjoint codebases.
Gnome telling SDL2 to link to libadwaita to draw clientside window borders is just cherry on top.
> Every windowing system in common use (and a dozen others) took that path. X11 is the odd thing here.
Every other graphical system did so by tying the protocol to an entire specific software stack; Windows/Android/MacOS/Haiku all require you to use their single official compositor and window manager. I get that you're arguing that's a good thing, but I pretty strongly disagree.
> IMHO the actual strategic mistake for Wayland was that they prioritized writing standards over iterating on a working reference implementation that was usable as a daily driver.
Hard agree, 100% yes; even if they'd just focused on shipping a single working example desktop environment, at least it would have forced them to figure out all the protocols that need to exist.
> You shouldn't need an alternative window manager any more than you would need an alternative trackpad firmware. It's supposed to be invisible. Draw the window borders using a plugin/subprocess, because your existing user base demands shallow "customization". Cover the 99% use case, and expose an API for extensions to do stuff like auto-tiling or shader effects.
I'm less convinced of that; people aren't asking for shallow customization at all, and I am skeptical of the idea that any one window manager could accommodate the needs of GNOME, compiz (yay cubes), and dwm. You'd also bake in technical choices that would sit badly with chunks of the population; odds are that we would have ended up baking most of GNOME into the graphical server and being stuck using javascript for everything, or gone the other way and committed to using C forever.
But overall, I tend to agree; personally I would have liked wlroots to effectively become the unifying point and have been part of the initial release, along with actually shipping most of the needed protocols up front rather than effectively leaving everything except drawing windows as a TODO.
I am a former dwm user (contributed patches too), and I'd say we represent a group of marginal importance. Suckless is as much a philosophy as it is a lifestyle choice. It proves that simplistic software can be practical, but skims over many in-depth issues, such as accessibility.
Once we get the elitists out of the way, the needs of the 99.99% are not that hard to meet: Windows & macOS combined market share more than proves it; tools like Hammerspoon or AutoHotkey fill the gaps for most power users.
> You'd also bake in technical choices that would sit badly with chunks of the population; odds are that we would have ended up baking most of GNOME into the graphical server and being stuck using javascript for everything, or gone the other way and committed to using C forever.
Hammerspoon uses Lua; macOS doesn't even ship a Lua interpreter or ObjC bindings.
Also, the majority of the population is not technically competent enough to even care about decisions such as JavaScript vs Guile vs Bash; power users in practice turn out patient enough to put up with garbage like AppleScript, because it gets work done.
The continued prevalence of memory unsafe languages is unfortunate, but a well-written and well-maintained C project used by a million people is going to provide more value than an absolute marvel of engineering, written in Rust, used by a hundred.
Take this redit post from someone with a bum shoulder, for example:
https://www.reddit.com/r/linux/comments/17oo98g/wayland_simp...
It's the second hit for "Wayland Accessiblity Protocol", so (I'm guessing) if there is such a protocol, it's extremely obscure and unsupported.
The first hit links to these two pages, which are separate lists of wayland accessibility regressions for KDE and GTK:
https://www.freedesktop.org/wiki/Accessibility/Wayland/
https://www.freedesktop.org/wiki/Accessibility/GTK-a11y-reva...
Of course, even if they address all the things on both lists (which is at least twice as much work as doing it under X11 was) none of that will help the person with a bad shoulder, since they need to mix and match between multiple environments to use their machine.
Another way to put it is Wayland with a few years of development by a few Linux players (others were building alternatives, while yet others were seeing which one would win out, and yet others were hoping to stay on X11 forever) under its belt, is almost as solid as X11 with many decades of development by all the Linux players.
The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong. X11 has been built and expanded for decades and even today is incapable of doing many modern functions that its competitors can.
Wayland, OTOH, has almost reached parity with X11 rapidly, does things that X11 is not even capable of, and has a roadmap to reach complete parity.
> The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong.
It's also not something anyone is arguing, and something that's not really meaningful because we have Xorg already. At best, you're arguing that Wayland actually has a chance to catch up even though it hasn't in the first 15 years.
> Wayland, OTOH, has almost reached parity with X11 rapidly,
Debatable but possible,
> does things that X11 is not even capable of,
Capable of without more extensions, but who's counting?
> and has a roadmap to reach complete parity.
Yeah, no. Wayland has roadmaps to someday hope to implement a lot of features, but explicitly is designed to not cover others and AFAIK has nobody working on others. There is not, and probably never will be, a wayland protocol to separate the window manager from the display server. There could be but AFAIK isn't any effort to let programs manipulate windows in a portable way (read: there will never be accessibility tools that work on all, or even most, compositors). Wayland is aiming for ~90% feature parity with X, and may someday reach it.
---
[0] I can think of some metrics you could use, but they're all hopelessly entangled in confounding variables. For example, we could graph number of X11 window managers released per year against Wayland compositors released per year, but even if you could pin down good numbers they're happening in completely different ecosystems and contexts. Likewise, we could make up a list of features and when they were added, but it seems a bit unreasonable to ex. hold it against X11 that nobody cared about HiDPI for the first ~30 years it existed.
If Wayland is going to be caught up and have feature parity so soon, then why can't decisions to deprecate and remove X11 be 100% put on hold until then?
> The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong.
Nobody thinks that. But at the time X11 was missing all of those important features, there wasn't another full-featured option that everyone was rushing to deprecate and remove support for to force everyone onto the immature and incomplete X11, at the expense of things that already worked.
Of course, there’s no reason that this has to be a separate process, it could just have been a library that everybody links to. wlroots looked like it could have been a nice library that provided a lot of that shared functionality, but then Gnome and KDE didn’t use it, so the predictions of fracturing seem to have come true.
But Windows 11 really achieves greatness in a lot of ways, which offsets it.
I'm not trying to be rude just genuinely curious, and I also don't use a DE, wayland or accessibility, so I have no horse in the game.
I run the OS that runs the programs I want to use.
Why wouldn't someone ditch an OS for another to keep using the software they want?
Probably because it was a legitimate question out of curiosity with a couple sub-questions, and "why not" is a dismissal rather than an answer.
So when you write commands you bind them in different way: app specific[1], feature specific[2][3], OS-specific, hecking __programming language specific__[4] etc, and then talon mixes and matches all of that stuff together.
So let's say I have VSCode focused on a javascript file . Talon knows this, and so I have "panel switch" which is a vscode specific command, and "op strict equal" to insert ` === `, but I also have generic text editing commands (because it's an editor), and multi cursor commands (because vscode has been tagged as multi cursor supporting), and tab commands (because vscode is a tab-based editor), and so on and so on.
If I then switched to the browser I would keep the generic text editing commands, and the tab commands, as it supports both of those things, but I would no longer have multi cursor support (or JS commands), because my browser doesn't support that.
This also means you can by and large use the same talon config (and so the same voice commands) on windows, mac and x11.
So for me switching to windows is actually less of a pain because most of the ways I interact with my computer don't actually change, as talon abstracts that away quite a bit.
[1] https://github.com/talonhub/community/blob/main/apps/vscode/... / https://github.com/talonhub/community/blob/main/apps/vscode/...
[2] https://github.com/talonhub/community/blob/main/core/windows...
[3] where vscode gets its features "bound" https://github.com/talonhub/community/blob/main/apps/vscode/...
[4] https://github.com/talonhub/community/blob/main/lang/javascr...
I have solved this by replacing my keyboard with voice commands almost entirely (I don't actually have a keyboard on my desk, but I can reach for my laptop keyboard if I really really have to), and am slowly working on replacing a trackball with an eye tracker (it's kind of headache-inducing though, so it's likely the trackball will stay for a while)
I'm not a medical professional but that sounds like a disability to me.
The odds are pretty good that computer-related RSI is similar to other computer-related RSI. I see no particular need to specify that I'm not talking about tennis elbow when that is already abundantly evident from the context. Most of my comments could include an accurate disclaimer that I'm not talking about tennis elbow, but it wouldn't improve any of them.
Real diseases often have a progression of permanent damage over time and real treatments have positive and negative interactions with other aspects of patient health, cost, and a wide range of outcomes. Commercials especially push a simplistic view that a person has a problem and undergoes a treatment and their problem is resolved. This is as real as crimes being solved in scope of an hour drama or as real if you prefer as people hacking by pounding on the keyboard really fast.
Most users in Developed countries have access to both doctors and the internet and have whatever level of problems they have in spite of pursuing treatment options and probably wont benefit from "one weird trick" to beat RSI.
When I hear accessibility I tend to think of screen readers - magnification or text to speech - for people with low vision.
Only on the internet would someone discuss a change they've made due to a disability, only to have someone else say challenge them on it and imply that they're bullshitting.
Accessibility is customization, and customization is accessibility. They are one and the same.
User control over interfaces is an accessibility feature. At the heart of accessible control schemes is the notion that if a user isn't able to use a traditional control-scheme they should be able to build or hook into something else or customize something that works for them.
This is a big problem with how the Linux community thinks about accessibility. Accessibility is not a separate concern from user agency and control. Accessibility IS user agency and control over a user's interface. It is the ability to take an interface you can't use or that is frustrating or painful to use and to adapt it to your needs.
Accessibility is fully aligned with Linux/GNU philosophy, but we treat it like a separate issue and like it's a chore to support, rather than being a central pillar of how we ought to be approaching software development in general.
----
Here, GP has RSI which means their customization is linked to a traditional physical disability. But to be clear, even if that wasn't the case and even if this just made their life easier and they didn't have a clear, socially accepted disability classification to point to -- customization is still accessibility. Gatekeeping accessibility or asking people to prove that they're fully "disabled" isn't really helpful, we should still be prioritizing making it possible to build things like this. And we should still be treating it like an accessibility concern regardless of whether there's an easily defined disability to point to.
For example[1] it doesn't know if you're using VSCode that you have focused the inbuilt terminal, and so it should now accept terminal commands (eg "cd <whatever>") until you focus back. It knows about the language that you are using because you have configured your text editor to have the file name in the window name, which it can reliably read. This is also how you have website specific configuration.
[1] last I checked! I think there was some work to try to solve this problem, I'm not sure where they got to though, I kind of went down my own configuration fork for a while
I can’t speak much to windows accessibility, although Mouse Keys got me through several rough times in my life where I fried or broke my mouse in some way or another. I do think windows has improved with time, at least by accidentally triggering the screen reading in W10 more times than I’d care to admit
At a toolkit level, you don't really have to worry about that. When developing GTK or Qt apps, most of the DE integration and Wayland/x11-specific features are handled for you automatically. Basic trackpad gestures, copy/paste and windowing heuristics are handled by the toolkit, and so is accessibility software if your toolkit supports it.
If an app doesn't work well on a desktop's Wayland implimentation, it is less often a Wayland problem and more a desktop/toolkit problem. We had the same issue with non-conformist x11 software, unfortunately.
Just no ability to launch windows at absolute positions or do non-standard input stuff (like special mice, keyboards, or keyboard/mouse sharing) unless your particular wayland flavor has libei. And some waylands like sway are actively hostile to libei. Which is kind of microcosm of the waylands as whole.
Projects like GNOME would have dropped AppIndicator and server-side decorations whether it was included in Wayland or not. Drilling-down on a minimal set of secure features was the only path forward if Wayland wanted developers to take the protocol seriously.
To the extent that we allow programmable interfaces outside of the terminal, we put those interfaces on top of the graphics stack rather than underneath it and we treat them like alternative control schemes, not common interfaces that every input device should be hooking into and sharing regardless of whether they're for some "disabled" category or not. Disability is a spectrum, having separate categories for "normal" interfaces and accessible interfaces doesn't capture that.
These problems are kind of universal, but X11 just happened to be so wildly insecure and had such bad encapsulation that devs could work around that problem. Which... better than nothing, I guess, but our primary way of mitigating accessibility problems shouldn't be to make our software worse.
I'm still on X11; I haven't fully figured out tablet settings and I'm waiting for OpenTabletdriver to mature a bit more before taking a serious dive into Wayland. But does being on X11 mean that my desktop is accessible or that I can test software that I build with a common screenreader to make sure it works for disabled users? No, of course not, I use i3wm where as far as I can tell accessibility software like Orca can't hook into any of the programs that I run, even programs with explicit support for Orca.
I don't think the problem here is the technology, the technology just reveals a deeper apathy that has always been present. It won't be fixed until we change our relationship with differently abled users and start working with accessibility communities on shared protocols/interfaces rather than treating those interfaces like afterthoughts. A lot of the "debates" about accessibility requirements like controlling window position, etc... stem from that issue and probably have solutions that would work for everyone if we prioritized finding them and approaching the problems from different angles.
TBC I don't have any educated opinions about Wayland (I don't know remotely enough to know if the decisions they made are good ones in the grander scheme of things), more that it's this looming existential sadness that I'll eventually have to give up on Linux.
And this is probably some form of "losing", but honestly WSL gets me pretty close to where I want to be in the getting shit done department. Just not in the "not using Windows" department ;-)
(MacOS is another fine option, but I literally bought a framework laptop a week ago, so that door is financially closed to me for a long while)
Accessibility work itself ironically suffers from an accessibility problem. I brought up i3wm above, the issue for that is pretty illuminating: https://github.com/i3/i3/issues/3393
It's not that the devs are saying "this doesn't matter", the devs behind one of the most popular tiling window managers in the X11 ecosystem are saying, "this does matter, but we don't know how to fix it. We don't know what changes we'd need to make to be accessible."
It's a tragedy because I honestly believe that if accessibility communities were more heavily baked into testing and development in Linux and if this wasn't treated like two separate worlds, it would be better for everyone -- fixing accessibility concerns very often improves interfaces across the board and makes them more powerful. Of course, it shouldn't be the primary motivation, but it's worth mentioning that every single screenreader is a potential adblocker, every alternative control scheme is a way to automate and script software, every comprehensive text-based description of an interface is a way to pipe that interface into a terminal and build tools on top of it.
There's a huge amount of potential, but how do you bridge that gap? I don't really know, I tried looking into Orca to see what would need to happen here and bounced off of it pretty hard, it's not a very approachable tech stack and there aren't tutorials or getting started guides. And on the other side of the issue I can preach about needing accessibility input during interface design, but I'm not in a position to give specific advice because I don't use screenreaders or alternate control schemes and I don't know what the biggest problems are.
The people who need to be involved in that process can't get involved because there's a tech barrier in place even for technically inclined people, and because the underlying software locks them out from the start. i3wm isn't ever going to get someone who's intimately familiar with Orca to jump into the conversation because the people who need to use Orca can't use i3wm. So that leaves the people who can address that tech barrier, but they don't know what to do or how to approach the problem because of the lack of involvement and because the communities are isolated from each other. So it's a chicken-and-egg problem and I don't know how to solve it.
For what it's worth though, accessibility was mentioned as one of the improvement area for which Gnome got funding: https://www.phoronix.com/news/GNOME-This-Week-Homed
Not sure what it will mean in practice, accessibility being a large topic.
The sad thing to me is that Wayland is aiming at replacing X while at the same time proudly stating that they aren't going to support a fair bit of the functionality that X provides.
That makes the whole effort an exercise in regression to me.
I'm planning on moving all of my machines from Linux to BSD in part because of this, and in part because of SystemD.
A first step might be to just have a list of all the functionality affected by fragmentation. So far, unfortunately, most such lists are accompanied by if not subsumed within angry rants.
> they would probably diverge from GNOME and KDE by doing so
Which would be something I could live with. I dislike Gnome quite a lot so don't care about that. I do use KDE, but it's nothing that would hurt too much to do without if necessary.
> and anyway they are generally loath to include or endorse graphical components in the base system.
I don't remember the others off the top of my head, but OpenBSD certainly seems to be treating Xenocara as a core part of the OS? It's not in the main src tree, but it's maintained in-house, the x* sets are treated like any other, and even some non-graphical programs depend on the xbase set for things like font rendering.
Most X apps these days use only a tiny subset of request types anyway (source: lots of time spent with xtruss) and most of what's left is easy to shim.
The X protocol is messy, but very little of it is used by software people both a) care about, and that b) isn't available in source form and can easily be upgraded.
Sometimes I wonder about taking wlroots and doing a FrankenCompositor with first class X protocol support, including window management and all the bits the Wayland proponents keep not wanting to add...