The future is Wayland. Let’s make sure we’re invited.
This post wasn’t supposed to exist — not yet. I meant to talk about bootloaders. About inaccessible USB installs. About the deafening silence between pressing the power button and hearing a screen reader. That post is still coming.
But something bigger is happening now.
- Ubuntu is dropping GNOME on X11.
- GNOME itself is removing X11 code.
- And in Red Hat Enterprise Linux 10, Xorg is already gone.
Not just deprecated. Removed from the repositories entirely in the long-term.
Fedora hasn’t removed the GNOME on Xorg session yet, neither has Ubuntu. But they will. Everyone will. That’s where this is going. Other desktops will drop x11 support.
And for those of us who depend on accessibility, that shift is seismic.
I Held Out. For Good Reasons.
Wayland used to mean losing access.
AT-SPI was fragile. Orca was inconsistent or silent. Flat review didn’t work. Login greeters didn’t speak. There were no logs, no fallbacks, no recovery paths.
X11 was ugly. But it was predictable. I stuck with it because it let me work — not well, but reliably.
Then I tried GNOME on Wayland.
And… it works. Orca is responsive. Focus tracking behaves. That ancient modifier bug where Caps Lock would stick after Orca commands? Gone. That was an X problem — and Wayland fixes it.
It’s not perfect. But it’s progress I can feel.
Xorg Is Going Away — Slowly, But For Real
The writing’s been on the wall for a while. But now it’s more than that.
Xorg isn’t just deprecated. It’s being removed.
Red Hat made it official in RHEL 10 — gone from the repos. Not available. Not supported.
Other distros are following. First it disappears as the default. Then as an option. Then, eventually, as a package. Ubuntu is almost there. Fedora’s right behind. GNOME no longer wants to maintain X11 support.
Yes, Gentoo will be Gentoo.
Yes, Debian will keep it until it won’t compile anymore.
Yes, the AUR will archive its ghost for years.
But that’s not a fallback you can depend on. This won’t be a clean cut — it’ll be a long, messy decline.
And the longer we wait to make accessibility real on Wayland, the more people we leave behind.
Developers Are Rising to the Challenge
Here’s the good news: I’ve talked to developers from GNOME, KDE, and Fedora.
They get it. And they’re taking it seriously.
- GNOME’s Wayland session is now stable and usable with Orca.
- KDE is catching up — and has a legally blind developer leading accessibility improvements.
- COSMIC is building Wayland from scratch with accessibility and global hotkey support in mind.
- For once, accessibility isn’t just a postscript. It’s in the room where design happens.
This transition is happening — but we’re not being ignored anymore.
What We Gain From Wayland
This isn’t just a funeral for X. Some things in Wayland are genuinely better:
-
Modifier key sanity.
Caps Lock doesn’t stick. No weird leftover key states after Orca commands. That’s fixed. -
Clean focus behavior.
Window focus events are less chaotic. Orca doesn’t get confused between apps the way it used to. -
Security that matters.
Apps can’t spy on each other’s keystrokes or windows. That means your assistive tech is safer by default. -
A real foundation.
X11 was a museum exhibit of patches and abandoned extensions. Wayland gives us something intentional. That alone opens doors to building accessibility right, instead of constantly duct-taping it on.
… But We’ve Lost a Lot, Too
-
Headless GUI workflows are broken.
On X11, I usedxorg-video-dummywith a custom/etc/X11/xorg.conf.d/10-headless.confto create a virtual monitor. Electron apps ran fine. I usedocrdesktop. I could automate real tasks with no screen at all.
Under Wayland? Nothing comparable exists. Electron apps lag or crash. The entire workflow? Gone. -
Desktop choice has collapsed — for now.
My Linux journey started at the TTY, then Unity, then MATE — the desktop I came to rely on most.
My first experience with a window manager was i3, and later I forked DWM to build something accessibility-first. I loved window managers: minimal, efficient, tailored to how I think.
On Wayland? That kind of freedom is on hold. GNOME is the only working option for now.
But KDE is moving. COSMIC is promising. Others will get there. I want that future back — not just for me, but for every user who deserves to choose how they compute. -
MATE isn’t on Wayland yet — and it matters.
Let’s be real: MATE was the preferred desktop for blind users under X11. Stable. Keyboard-accessible. No surprises.
It doesn’t support Wayland yet. I hope it does. I hope it’s done right — not half-baked, not bolted on. Because while I enjoy solving problems, not everyone wants to live in a constant battle. And they shouldn’t have to. -
We lost an ecosystem.
xdotool,xclip,xwininfo,ocrdesktop, all the little tools that made scripting, testing, OCR, and interaction possible — broken or unported. Not impossible to rebuild. But we have to start over.
Compositor Compatibility Is Still a Minefield
Let’s talk about something most people never notice: how your compositor handles input and permissions.
If you’re a sighted user, you can probably switch between Sway, Hyprland, and Wayfire without a second thought. But for those of us using screen readers, that freedom vanishes quickly.
- wlroots-based compositors — used by many lightweight Wayland setups — still don’t reliably support the D-Bus keybinding interfaces that Orca depends on. I’ve heard of people getting them to work — sometimes — but often not on laptop keyboards, where modifier handling is especially flaky.
That means most tiling Wayland compositors are effectively inaccessible out of the box. Until they implement proper D-Bus-based keybinding forwarding, you either use GNOME or lose speech.
And then there’s XDG portals.
I agree: portals are the future. They're the right abstraction. Done well, they’ll let us build accessibility features, input emulation, screen capture, scripting, and more — without depending on insecure hacks.
But today? It’s chaos.
Each compositor can ship its own portal implementations. Some are incomplete. Some are buggy. Some are missing entirely. There's no consistent baseline. One portal might support accessibility events, another might break flat review, and a third might not support screen capture at all.
We’re supposed to be moving forward — but when every compositor speaks a different dialect, users fall through the cracks.
We need consistency.
We need a minimum set of working portals and interfaces that every compositor supports — not just on paper, but in practice.
And to be clear: this isn’t GNOME’s fault.
I know hating on GNOME developers is popular. I’m not doing that today. GNOME is the only reason Wayland accessibility is usable right now. The work they’ve done is real, and it’s miles ahead of anyone else.
No one else is quite on GNOME’s level.
KDE is trying — seriously trying. COSMIC too. I know that because I’ve spoken to the people behind them. They care. They’re listening. But GNOME is still the only desktop where accessibility isn’t a maybe — it’s a working reality.
That has to change.
And it starts with every compositor agreeing on what “accessible” actually means.
We Can Still Build Something Better
This isn’t just a painful transition. It’s a rare moment to rethink everything.
- A modern
ocrdesktopusing PipeWire. - A
waydotoolthat speaks AT-SPI and respects sandboxing. - Headless GUI support that’s built on purpose, not hacked together.
The architecture is there. The interest is there. The people are listening.
Now’s the time.
I Still Want to Love Linux
So I’m using Wayland now.
Because I have to.
Because X11 is heading toward the grave.
Because I want to help shape what comes next — not just mourn what came before.
This is our moment to make sure accessibility doesn’t get erased in the name of “progress.”
To build something better — not just shinier.
Wayland is growing up.
Let’s make sure it doesn’t grow up without us.
And to the developers — the ones fixing bugs, wiring up events, untangling toolkit chaos, and answering hard questions with humility:
You are great people doing great things.
Even when it’s frustrating. Even when it’s thankless.
Thank you. You're the reason I haven’t given up yet.
Oh — and apparently, I’m a Wayland shill now. Didn’t see that one coming either.
Give me a possibility to switch the keyboard layout in cinnamon on wayland and I will consider granting it an early alpha status that may lead to a usable stable version in a few years.
The random bolding pattern and some other small things makes this feel written by ChatGPT.
I think a lot of this was good, but if you just removed all the bolding the reading experience would be like 30% better.
I want to be able to use Wayland. I really do. But if the only practical way to do that today is while also using GNOME or KDE, I'm totally out of luck. In general, GNOME's user experience is the drizzling shits, to put it politely. KDE's is better, but it's just too damn bloated and memory-intensive for what it offers. If those are my only options, well, I might as well just go back to Windows and use WSL, or use macOS.
The main reason that other compositors don’t support any accessibility protocol is that there isn’t one yet. GNOME uses its own bespoke interfaces and integrates directly with relevant tooling out of band and in highly coupled ways. It’s infeasible for other compositors to imitate this.
Before we can even ask compositors and libraries like wlroots to support accessibility protocols, we need those protocols to exist.
The situation isn’t any better for clients. I’ve written a couple of small clients and it bother me that they’re not usable with screen readers. It bothers me deeply. But there’s nothing I can do about it: there’s still no extension for a client application to inform the compositor of anything related to accessibility. Just like there isn’t any way for a screen reader to talk to the compositor. Addressing this requires designing a protocol for clients to exchange accessibility information with a compositor, implementing both the client and server portions of this, then designing a protocol for screen readers to talk to a compositor, and finally implement this in compositors and screen readers. That’s a multi-person multi-year undertaking.
And please, PLEASE, let’s not make something as important as accessibility depend on portals. Portals are a huge mess, a quick hack to get things out fast without any sensible design. It piles dozens of unrelated features into a single monstruos interface. Its security model is a joke. It doesn’t even have an interface for sandboxing engines to integrate; they need to patch the XDP instead. And requiring 3+ daemons for a client to talk to the compositor is absurd, considering the client needs to have a direct connection to the compositor anyway.
We really need to focus on designing interfaces which different components can implement. In fact, I’d actually love to collaborate on this kind of work (assuming I somehow manage to fund it).
Yeah, the lack of consensus on wayland standards is certainly a pain. My understanding is that its development contains a lot of conflict as to what should be included and supported and what should not. Likewise, while I understand that not everyone wants to build on wlroots itself, I think that making its protocols available in every compositor is a necessity. Ideally, if you're building a window manager, your goal is probably to focus entirely on the window manager itself. As a result, using a consistent set of protocols, filetypes and bindings is a really good way to ensure you can stick to that task. I think the best thing developers of window managers and compositors can do is not to ask what protocols they whether to build their own protocols, but to instead support as many as you can from as many different window managers as you can, such that people can take their own existing tools, and use them with your window manager.
Lxqt and cosmic have both displayed an interest in supporting interoperability between their desktop environments and wayland window managers. So I think that making your window manager as cross combatible with as many of their tools as possible should be a top priority for many devs. Cosmic sounds like the right choice based on your post.
You spoke much about desktop, but how is the currwnt Orca development. Are they ready for Wayland? Do they use modern concept?
A well-written post as always! And also, thank you for pointing out the problems with portals. It's maddening that there is no baseline, yet Flatpak is being pushed as "the future for apps".
As someone involved with Gentoo, please note that we also focus on Wayland! We have no intention of going against the currents of DE developers :-)
Thanks for sharing this and clearing up some of the FUD around Wayland accessibility.
So accessibility still isn't fixed under wayland. The security features touted by Wayland means that individuals with mobility issues can't utilize it. I have nerve damage in my hands, which makes utilizing mice and keyboards difficult without alternative input devices. I use the Talon voice software package to perform key presses,mouse manipulation ,position windows, focus application windows, and change how my voice commands are processed based on which application is in focus. On every non-linux os, this functionality is available to accessibility applications. On Wayland, these features are impossible because of said security, though some compositors provide hackish workarounds. There's more to accessibility than screen readers. Some of the very features that make the display less secure are absolutely required to enable accessibility tools. As it stands I will have to abandon Linux unless Wayland addresses these issues.
https://github.com/splondike/wayland-accessibility-notes/blob/main/talon-requirements.md
Since you said that you have to use Wayland now, I wonder why that's the case. It looks like currently there are more positives on the X11 side.
Are the modifier keys and window focus events valuable enough to give up on the lost features? The fact that Xorg is slowly going away is not a problem right now, and certainly not one many distros would have, since most DEs and WMs still rely on X11 and will ship the necessary software to enable them.
I'm curious about this because I wonder if losing those X11 features actually matters that much, or if you preemptively moved to Wayland in order to be ahead of the curve, so to speak, and even contribute feedback along the way. And does the loss of features have the same impact for everyone visually impaired?
Ah yes, another lament from a casual user stranded in the sandbox that corporatized computing built. Welcome to the consequences of not reading the source, my friend. You're upset that Wayland “doesn’t give you a choice”? Cry me a river of proprietary drivers and binary blobs. This is exactly the kind of creeping authoritarianism that happens when people let corporate interests steer development instead of users who actually give a damn about freedom.
Look, I’ve been in this game since before PulseAudio was a glimmer in Lennart’s eye. Back when you compiled your own kernel because you cared, not because some distro wizard told you to. X11? Sure, it was a beast, but it was our beast. Ugly, complicated, and full of historical crust—but I could script it into a ballet if I wanted to. Wayland? It’s the Ikea furniture of display servers: minimal, pretty, and ready to break the second you ask it to do something useful that wasn’t blessed by the “compositing gods.”
You say “we don’t have a choice”? We always have a choice. You can pry my
.xinitrcfrom my cold, calloused, C-worn fingers. You can keep your sandboxed Flatpak slop and your D-Bus-riddled desktop frankenstein. Some of us like being able to SSH into a box and forward X apps over a potato-powered VPN without crying. Some of us like controlling our own software stack. And some of us still believe in RMS's dream—not this sanitized, containerized, freemium-fueled dystopia you're all sleepwalking into.So no, I won’t give Wayland a medal just for “growing up.” It’s growing up into the wrong kind of adult: sleek, obedient, and neutered. If I wanted that, I’d be using macOS and selling my soul for a notched screen. I want freedom, not frictionless tyranny with a GTK theme.
Come back when you’ve compiled your own display server, friend. Until then, welcome to the shallow end.
Honestly I went from fuck Wayland to 'let's all use it' very, very quickly, especially in the last few months. I tried it multiple times. I remember Ubuntu 19.10 replacing the default Gnome session with the Wayland one and I wasn't happy about it at all, it basically kickstarted my hatred towards Wayland and I've avoided it like a plague, untill now. I decided to take the plunge and try out SteamOS 3.7.11 on my ROG Ally now that they started shipping Orca by default, and holy shit, the level of usability out-of-the-box that I got was quite frankly something I've never really experienced, especially not from any kind of mainstream Arch based distro. Orca on the KDE Wayland session? Just works TM. Seriously. Absolutely none of the issues I've experienced even in Orca 47 exist. If you didn't tell me it was running on Wayland, I wouldn't have had a clue. The Gamescope session with Steam? Also works perfectly. In fact, I'd go as far as to say that Orca is actually more responsive with it than NVDA ever was in big picture mode. Basically, I kept switching to Linux, then switching back to Windows / Mac OS for practical reasons, it just wasn't worth the headache for me anymore, I'm not 14 and willing to distro-hop or reinstall 3 times a month or more like I was doing in 2019 - 2020. But I feel now is the time to try, and hopefully succeed, for the final time. Bazzite making VFIO / IOMMU passthrough a oneliner command should make this transition much more smooth as well.
portals are the future? Wayland's security changes are treated as a legitimate "benefit"? Hardcore yikes. If the future is sandboxed flatpaks, count me out of it. The X11Libre dev seems a bit whacked, but at least he's not pushing that.
Okay so aside from diabetes, I'm pretty abled for disclosure sake. Excuse me in advance if I am being ignorant....
First off this is an interesting write-up, because there are many concerns here that I've never truly grappled with. From what I've seen this is not trivial, and I know many in the community are fretting over the fact that Wayland basically resets the board... Most of the old tooling simply doesn't work and X11 mode has been rotting in maintenance mode for years now... And I do agree with developers when they say it can't be saved, given that the ones that are talking are the ones that have been working on the thing for years. However, this is a community that is totally dependent on the way X11 works, good or not.
I think the overall discussion over Wayland has been the simple fact that it's not a drop-in replacement, it works quite differently from X11. By design, and any attempt to revisit that is met with hostility. There are a couple of things that I think are going to need more work to get the kind of accessibility that users want and depend on. The big thing here is that Wayland isn't the answer for everything, because X11 tried to do that... And became very brittle as a result. Look at PipeWire, which has basically runs under a simple philosophy that Wayland builds under. Wayland is a display protocol, it is only a display protocol. PipeWire is multimedia protocol, and that is all. I think there are many things that Wayland can provide for accessibility however... There's likely going to need to be a separate protocol/library to handle several things that users will need for accessibility and not all of them will be in Wayland, PipeWire or other tools like libinput, etc. I know that it's a lot of work and time but I don't see another way where this gets done right. To add to that, my suggestion to you is to keep talking to the window manager developers... KDE, in particular, seems to be moving rapidly to being more and more stable under Wayland. However if accessibility takes a drop, this community will not see that improvement.
It is a little bit interesting that you singled out GNOME here, but I can understand why. That is a community that did a lot of work on accessibility on top of its transition to Wayland pretty early. As a result, quite a few things work very well. The problem... As Hugo mentioned, what GNOME does is very bespoke (which is something of a habit throughout the project) to the project. Quite a few other projects are going to have to do something on their own, and that's going to take time. What makes it worse is that quite a few projects never really thought about accessibility because of the way that X11 worked; where, in many ways, they didn't have to think about it because they just had to adopt the protocol. This is what made X11 suddenly become an operating system onto itself, which was never good. In Wayland, that isn't a luxury because if it's out of its scope, it's out of its scope. Wayland is a display protocol, not that plus a print server... It can't be a side thought anymore. For all the crap GNOME devs gets (some of it deserved, most of it not) they put in the hard work for their community and it's begin to pay off.
As for the issue with portals... I think you have to come to the realization that distributions no longer really want to "package the world". As much as it sucks, it's between flatpaks and snaps now... So this is a bridge that has to be crossed at some point and that also means that you have to deal with X11 own failings again (a majority of packages in flathub tend to run an X11 mode, and forces the use of XWayland... Especially the proprietary software packages). Again, alot of work to be done but it can be done I think.
I try Wayland composers about once a year. I found Hyprland much better than Sway. But it still took me weeks to replace all my existing workflows. flameshot on sway/hyprland on Gentoo is still broken, and the only option seemed to string together a bunch of other tools in shell scripts to get anything close to useable screenshots.
Basic things like Gnome keyring wouldn't even launch and unlock critical keyrings (I found a workaround using Seahorse).
But the biggest disaster are monitors. Using a KVM switch, you can't tell any composer to treat a monitor as if it's still there but disconnected. Not KDE. Not Sway. Not Hyprland. i3/X11 handles this fine. With X11 I can run xrandr and see every disconnected adapter. There is NO way to see disconnected adapters using swaymsg, or any of the hyprland tools. wlrandr cannot do this either.
If you disconnect the only monitor, most composers will simply crash. (Sway and Hyprland did, not sure if KDE can handle this now).
Two simple things: ignore monitor disconnects (for KVM switches) and show me all my disconnected interfaces. Impossible on Wayland, both wlroots based and others.
You cannot simply write a complex Linux app anymore that works across all window managers. Basic apps for displaying text, video and images: yes. Interact with the clipboard or screen or, heaven forbid, other applications: You're in for stabbing pain.
If Wayland was really better, everyone would have abandoned X11 years ago. X11 allowed a really good separation. You have one thing that handle windows, and other things that are applications. It's the RIGHT abstraction. I understand network transparency wasn't useful, but that's not the only thing that's broken now. No matter how much the basic use cases might work if you use KDE/Gnome or one of the big environments, every single advanced tool has to be individually custom tailored to every single composer. KiCad has several things that they cannot get to work in Wayland. No audio tools (DAWs) work at all on xwayland.
Wayland is a disaster and mess and I don't see X11 going away ever. i3/X11 has worked for me ever since I moved off of the disaster of gnome3 in 2012. I'll keep trying when I get time, but the entire Wayland project just reeks of IBM/Redhat elitism, allowing no reasonable compromises.
I can't speak to the accessibility in either case. I once worked at a big open source shop where every developer used Linux. The only exceptions were our graphics people and our accessibility engineer who was blind. He still used Windows, because at least back in 2012, the accessibility options in all the Linux distros he tried were not good. He left that company to be a life coach, so I'm not sure if he really cares that much about Linux anymore.
Quote: "I use the Talon voice software package to perform key presses,mouse manipulation ,position windows, focus application windows, and change how my voice commands are processed based on which application is in focus. On every non-linux os, this functionality is available to accessibility applications. On Wayland, these features are impossible"
I agree, Wayland needs global accessibility permissions for global window access and global shortcuts and so on. It seems like for controlling input, a part of this might already exist: https://gitlab.freedesktop.org/libinput/libei
But in overal, the best place I have found so far where one might bring up needed functionality is here: https://github.com/AccessKit/accesskit This seems to be backed or somehow have at least an indirect involvement of GNOME developers (sorry if I got this wrong, it's just what comments on the gitlab suggested). This project seems to be trying to solve this in a way that is reusable from all UI toolkits, and to add in all the protocols on the client side, while trying to figure out how to integrate this with common compositors. I imagine if some specific accessibility functionality isn't available, like accessing another window in some way, then this project might be a good place to feature request it.
It will probably take a while before all of this works. But it seems like the central projects to handle all of this properly are getting off the ground, at least.