A great writeup on the experience of blind users navigating GNU/Linux and the many pitfalls that prevent them from being able to use their machine.
Linux “just works”—if you can see.
If you’re blind? You boot into a live image and get nothing. No speech. No braille. No login prompt feedback. Maybe Orca starts, maybe not. Maybe you know the shortcut (Alt+Super+S?) but does that even work in this session type? Is it Wayland? Is it X11? Is the screen reader bound to a key combo that doesn’t exist on your keyboard?
You open the installer?
“Next. Button. Button. Button. Button.” That’s all Orca says.
Ubuntu MATE 12.04 had a working, labeled, navigable installer. Ubuntu MATE 24.04? It’s garbage.
No headings. No structure. No sense of where you are. Just unlabeled buttons and blank space.
This isn’t a bug. This is neglect.
I think a great takeaway from this is that a11y finds itself at the end of the pipeline, as the last thing that needs to be done.
Thanks for sharing this. I’m surprised to hear the situation is so rough. All the pieces seem to be there, and it is easy to assume “Someone is working on this. Someone is keeping on top of the situation,” but clearly that is not the case.
One of the key issues is that disabled people can’t build the accessibility they need to participate. There’s no “contributions welcome” that one can say.
It’s a very dire situation, but I’m glad this is getting more attention in the community. This is probably one of the most important blogposts I’ve read in a while.
The author has a follow up article and I’m dying lmfao
You Call This a Stack?
People call it a stack.
But it’s not.
A stack implies layers. Order. A single interface at each point.
This is not a stack.
This is a tangled mess of everything ever built for Linux audio still being required right now because no one can kill anything off without breaking something else.
You want to play sound? You need:
- ALSA, because it’s the actual driver
- PipeWire, because it’s the new standard
- Pulse emulation, because most apps still use Pulse
- ALSA plugins, because some things bypass PipeWire
- JACK shims, because a few pro audio tools never moved on
- And config files for all of it—if they even exist
This isn’t backwards compatibility.
This is a graveyard, and we’re all just camping in it.Edit: In my personal experience things have gotten a lot better since PipeWire was introduced, but the author is correct that whenever this shit breaks (or malfunctions) it is incredibly difficult to debug. There are so many layers, each with their own logs, and you’re lucky if they even log anything relevant to your problem in the first place. For all the hatred and death threats Lennart Pottering recieved for introducing systemd into this world (which is fine, actually) his real crime was PulseAudio. :)
That’s just audio. they didn’t even mention WiFi/Bluetooth. It’s 2025 and there are still issues, especially with Bluetooth. I shouldn’t need to open a bluetoothctl command window to re Bluetooth pair a device everytime I connect it to something else and then try connect it to my Linux machine again. Pulse audio on top of that makes reconnecting speakers or headphones that you used with another device a shot in the dark at times.
Yeah, BlueZ is flakey. My only experience with it pretty much is using wireless videogame controllers, but sometimes there are sporadic latency issues. Sometimes it just won’t discover a device. Sometimes it works fine. Sometimes just flipping between tabs in the Gnome Settings app will cause changes to the state of Bluetooth discovery, causing missing devices to finally appear. launching the TUI
bluetoothctlapp (and doing nothing else) can cause missing devices to finally appear. And sometimes it won’t. The d-bus interface seems robust, but d-bus itself is very poorly documented for application developers.That said, the world is full of really shitty and incomplete implementations of Bluetooth, and for all the faults of BlueZ it is at least fairly comprehensive. A lot of hardware is not tested for robustness against multiple implementations. If it can pair with an iPhone, they’ll ship it whether or not it works with Android, Windows, Linux, your shitty car audio system, etc, or any combination of these devices.
Speaking only for myself, I have not had any issues with WiFi in a long time.
Edit: Just because I missed this
they didn’t even mention
WiFi/Bluetooth.Oh, they do. That has its own section in the article.
Yeah at least there’s a command window/tool in Bluetoothctl with comprehensive commands to troubleshoot and turn it on and off again when it stops working. So there is always a fix, it just may take some time to figure out, with pairing, unpairing, trusted device, authorising services, etc. I’ve given up on using the UI based stuff like the standard GNOME and Blueman UIs for Bluetooth, the way it interacts with what’s actually going on under the hood is flaky, unexplained, or just straight up random.
But for Bluetooth audio devices, bluez + pulse audios Bluetooth audio implementation is a match made in hell. A word of advice: don’t manually enable pulse audios Bluetooth auto connect via the config file or any UI that can edit the config file. It will break Bluetooth scanning and discovery in modern Linux, it’s disabled for a reason nowadays.
WiFi seems to be mostly fine nowdays, the odd drop here and there, but I experience the same on my phone or when I boot into Windows. And the UIs have been updated to accurately reflect what’s happening under the hood.
