HN Reader

Wayland is great and ready for (idk) 95% of users/use-cases.

There is a long tail of more-or-less critical stuff that depend on X11 and do not have working Wayland substitutes. While the tail has been shrinking for every year, it will be decades if ever until all can be realistically migrated. Consider the Lindy Effect and that some of these systems have been running for >10y already. Consider shared but secured environments at universities and research institutes. Consider obscure hardware incompatibilities and hardware-specifix performance issues which might never be fixed.

On the software side, acessibility aside, there are a lot of VNC and other remote-X setups out there with no viable replacement in sight (yet).

Alsa, pulseaudio, pipewire and jack can all coexist and so can display servers.

I understand GNOME and RedHat will do things their way. I understand distro and GUI framework maintainers wanting to reduce their load. I understand people who like Wayland, want it to succeed, and want to evangelize. I do not appreciate when it turns into tribalism, forcing of monoculture and insisting "X11 is deprecated".

---

OP is from 2023 but as they note in their update, the situation is fundamentally not that different 2y later. Are maintainers and decision-makers really sincerely imagining that a supposed deprecation and removal of X11 can be forced onto the wider community over a couple of years from now?

I am a part of the Talon community mentioned here, use Orca, have contributed to the Rust atspi bindings and feel like I know Linux accessibility quite well.

It is true to in Wayland you can write protocol extensions or custom compositors to get around these limitations. However, what many fail to realize is that the primary challenge in Linux accessibility is not just a technical problem as it is getting people to actually implement specs and care about it. Even with atspi itself, a standard that has existed for over a decade, major apps like Firefox often do not implement the atspi Collection interface. This is not a criticism but rather a practical statement that accessibility needs to be standardized and easy to implement for it to actually have any use. Orca works on Wayland but only in certain compositors. For assistive technology software developers, this pattern of supporting specific compositors is not feasible. It is important to understand that we need to support assistive tech generally. Not just ad hoc extensions for certain types of disabilities.

Wayland has no concept of global coordinates or global key bindings. The protocol itself is designed around atomicity which is a nice concept, but is fundamentally in conflict to the need of assistive technologies to control the entire state of the desktop globally. As such, atspi methods like get_accessible_at_point are impossible in Wayland.

I agree that X11 cannot be carried on forever, but with the current state of Wayland, the phasing out of X11 will have the effect of drastically harming the accessibility ecosystem. Accessibility is not a "nice to have", it is essential to the mission of community inclusion and wider goals of adopting desktop Linux in education and government.

It's been almost two decades and we're still taking steps backwards on accessibility and features because of Wayland.

From day 0 Wayland put their idea of a beautiful design above the needs of users. It's hard to see how we can claim to be inclusive when even our most basic decisions are hostile to large groups of users.

I never thought I would say this, but after 30 years of open source and Linux I don't see much of a bright future. Everyone I know from the community back then has moved on to using a Mac because of these issues.

I was speaking at a conference recently and was asked to chair the session at the last minute. It was hybrid, so all the speakers needed to share their slides on Zoom. I have been daily driving Linux for 14 years, and this has almost never been a problem (there was a moment with i3 but it seems better). But I hadn't bothered to test this since installing (and generally loving!) PopOS COSMIC.

The problem, at root, is Wayland. Zoom has some kind of workaround it seems, but it's not working yet in COSMIC.

The result was sad: speakers having to speak with their slides being run by one of the remote speakers, and anyone who recognized the computer running Zoom as Linux surely strengthened their conviction never to try that.

The way to combat these problems is to form some foundation, secure funding (public and private) and hire devs to work on it across ecosystem.

The Wayland protocol "lacks" some things "by design" in that they are not specified. However, this is not intentional omissions, not even under the guise of "security", it's stuff that simply hasn't been done yet.

The most promising work towards improving accessibility support in Wayland was the work done on the Newton protocol:

https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the...

Unfortunately, the project appears to have stalled. I think the Linux desktop just lacks important strategic investments, and this is one of them. For now, existing accessibility bus support in UI toolkits is mostly being leveraged. Some compositors (i.e. KDE's kwin) also can support some old X11 features used for automation/accessibility (i.e. XTEST works, although applications will need to be granted permission first)

The situation is somewhat similar for IME: There are a few protocols for handling basic IME/text input, but it's not really finished, and further work on text input protocols has stalled.

This is not an ideal state of affairs at all, and it is a major threat to the future of the Linux desktop. I doubt many Wayland proponents (of which I do consider myself to be one) seriously believes that shipping Wayland-only without robust support for accessibility or internationalization is really a good idea. It's basically only happening because progress on Wayland has been rather slow, for many reasons, a lot of which really aren't in the control of open source contributors or maintainers. However, at the same time, maintaining both X.org and Wayland paths everywhere forever is also not sustainable: with limited resources, there simply has to be a point at which the line is drawn. X.org outside of XWayland has been unmaintained for a fairly long time.

On the flip side, if anyone working on Newton or Wayland accessibility has any idea what anyone on the outside can do to help things along, we'd love to know. I really hope that one of the major investors in the free software desktop (Valve? Red Hat?) can be convinced to help shift some resources to this. It's one thing to have some software work somewhat sub-optimally (as is the case with KiCAD), but it's a bigger issue that users who upgrade to newer free operating systems may face a system that is not usable for them because of limited accessibility tools. Possibly a compliance problem for companies that wish to ship systems based on free software desktops.

sounds like some peeps could contribute code to fix wayland / compositors to enable talon's accessibility hooks :D

On the flip side, there's some software that works (somewhat) with wayland but deliberately breaks compatibility.

For instance, Scribus uses QT which supports wayland, but they hardcoded a check to explicitly detect wayland and exit if it's found. You get the generic QT "supported backends" message that lists wayland, but if you actually try to use it the logic resets your choice, gaslighting you into thinking you typed the backend detection or override env var isn't working.

You can get around it using a wayland-flavor that they forgot to reject, and there are bugs (not sure how many are from wayland itself and not Scribus though) so I get not wanting to handle wayland related bug reports, but having buggy software is often than having no software at all so I wish they didn't choose the nuclear option (and now they get "please support wayland" bug reports instead, so...).

I think Krita is the same? There were a couple programs I had to dig into the code to work around blocker mechanisms to get to run.

All of this was well known when Wayland was developed. They just didn't give a shit about end-users. They had one or two specific things they personally wanted done, and they made sure that was supported, and that's it. And then a few major players decide they're going to push for this new system to become the system, so it's not just "a bad alternative", it's an unavoidably bad fate.

This isn't the first case like this. The Linux desktop ecosystem has been getting worse for years, as a few major players force systemic changes that make the system more complex, more brittle, and less compatible [with anything that came before it, or that doesn't use the same core components]. I've been using a Linux desktop for 25 years and it's never been more complicated or broken.

It's part of a larger trend of tech enshittification, but seems especially sad in the Open Source world. I always figured a decentralized, leaderless ecosystem could fight incumbent stagnation and selfishness, through the creation of alternatives. But some things there's just no alternative to. And apparently the list of things without alternatives grows.

It's impressive how I've seen quite a few accessibility complaints about Linux, and not a single bit of praise when people fix something.

Again.

<expletive> ANY Linux project that strongly breaks backwards compatibility.

Not surprised that it's still messing with people even this late in the game.

Wayland is a protocol for talking between the compositor and an application.

AT-SPI is a protocol for talking between the compositor and an accessibility reader.

It's not in Wayland's jurisdiction to define how AT-SPI should be used.