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?