Linux Is Already Broken Before You Even Start

I love Linux.
I use Linux.
It has its advantages.

It’s responsive—sometimes.
Some things just work plain better.
Settings being stored in actual config files instead of opaque registries? That’s an accessibility win.
When something breaks, you don’t have to reinstall the whole OS like you would on Windows.
Most importantly: it’s mine. To do with as I please. To fix, break, rebuild, and own.

And let me be clear:
This post is not an attack on the people who maintain Linux accessibility.

I have huge respect for every single person who’s ever written a patch to Orca, BRLTTY, speech-dispatcher, AT-SPI, or any of the dozens of tools that make it possible to use Linux without sight.
They are often doing it for free, in their spare time, while fighting upstream changes, toolkit breakage, and general apathy from distros and desktop makers.
They are heroes for making it work despite all that.

And before any neckbeards leap in with:

“Be the change you want to see.” “Code it yourself.”

Yeah. I know.
I try. When I have the spoons. When I understand the stack well enough to do more than write a bug report titled “it no work.”

But I shouldn’t have to.
And if that’s all you have to say?
Stop reading. I don’t care.

Let me be blunt:
This isn’t a rant from someone who gave Linux a shot and bounced off.
This is from someone who’s used Linux full-time for years as a blind user—someone who knows the system inside out, who has made it work through manual configuration, scripting, rebuilding broken packages, and sheer force of will.

And still?
I’m exhausted.

Because Linux doesn’t fail at the margins.
It fails at the very first step.

Before you open a terminal.
Before you write a line of code.
Before you even get logged in—the basic, day-one functionality of accessibility is already broken, decaying, or actively getting worse.

“It Just Works” — The First Lie

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.

Logging In Is a Joke Now

Used to be, on Ubuntu MATE, you could hit Alt+Super+S at the login screen and get Orca.
Now?

• You hear a drumbeat sound.
• No speech.
• No braille.
• No way to start the screen reader.
• No visual confirmation—unless you can see.

And if you do start Orca manually after boot?
It doesn’t persist.
It used to—years ago. Now? Every login you start from scratch.

You want persistence?
You download a random shell script from GitHub.
You patch your own session files.
You maintain the config yourself—because no distro ships it working.

The Audio Stack: Now With Extra Failure

Let’s say Orca does start.
Now the audio stack kicks in.

Is it PipeWire?
PulseAudio?
Is ALSA enabled? Is the correct fallback sink selected?
Is the audio device owned by root? Is the socket exposed to your session?

Who knows. Because:

• Pulse loads the wrong output.
• PipeWire can’t access your card.
• Speech Dispatcher is stuck waiting for a disconnected device.
• You log in and get nothing. No error. Just silence.

Want to debug it?
You can’t—because you can’t hear anything.
So you grab your phone, take a picture of the screen, feed it to an image captioning AI, and hope it tells you whether the error dialog says “Audio device unavailable” or “Session startup failed.”

This is normal now.

Console Speech Exists—But It’s Never Set Up

Technically, yes, you can get speech on the console.
Linux Speakup exists. It’s been in the kernel for decades. It supports software and hardware synths.
You can log into a tty and use your machine without graphics.

But no one enables it.

• Your distro doesn’t load speakup_soft.
• It doesn’t start espeakup.
• It doesn’t ship the synth module in the initrd.
• The audio system might not even initialize before espeakup starts, so it fails silently.

So even if you drop to single-user mode—say, because the GUI broke—you get nothing.
Not even an error.
You sit there with no speech, no fallback, hoping you can remember the exact keystrokes to get to a working shell blind.

You want it to work? You have to:

• Install and enable Speakup.
• Patch the initrd.
• Rebuild your audio stack.
• Debug the TTY config.
• Pray you didn’t forget a kernel module.

Scripts for Everything. Everything.

You want:

• Persistent Orca? Script.
• Speakup at boot? Script.
• Audio from root piped to your user session? Script.
• PipeWire to accept connections from other users? Script.
• Braille support on boot? You guessed it. Script.

Linux accessibility is now a collection of random shell scripts pulled from mailing list archives and pasted into local hacks, maintained by one person somewhere, and maybe still working.
Maybe not.

This isn’t how anyone should be expected to use a computer.
But it’s our reality.
Because no one has made any of this standard.

“Secure by Design” Means “Locked Out by Default”

Running ALSA as root had one huge benefit:
If the desktop died, you could still get speech.

With PipeWire or PulseAudio, audio is bound to a user session.
That session can’t share audio with root.

So if GNOME dies, your login session fails, or you drop to a root console?
You get silence.

You want root to send audio to your user session? You have to:

• Set up shared Pulse sockets in /run/user/1000/pulse/
• Reconfigure PipeWire with cross-user permissions
• Start a session bus with the right UID
• Patch a service file to allow root access to a user-owned socket

Which breaks again the next time you update PipeWire.

Security is great.
But not when it blocks your only method of interacting with your machine.

Accessibility Comes Last (If It Comes At All)

GTK3 broke accessibility for years.
GTK4 released with no accessibility support at all.

Not a single accessible widget. No keyboard nav. No AT-SPI integration.

Why?
Because accessibility was never tested.

Wayland? Same thing.
They broke Caps Lock as the Orca modifier.

That’s the key blind laptop users depend on—because Insert doesn’t exist on most modern keyboards.
With Wayland? You’re out of luck. You can’t remap it. You can’t fix it.

GNOME eventually patched it.
Other desktops? Still broken.

This took years.
Because no one outside GNOME tested it.

This is the pattern:

• A new system gets released.
• It breaks accessibility.
• Nobody tests it with a screen reader.
• Eventually, someone screams.
• Maybe it gets fixed.

Maybe.

MATE: The Last Accessible Desktop Standing

If you want to run a graphical Linux desktop and actually get work done using a screen reader, there’s only one option that consistently works:
MATE.

MATE isn’t flashy.
It’s not modern.
It’s not innovating like GNOME or spinning UI metaphors like KDE.

But it speaks.
It tracks focus.
Orca behaves.
Keyboard navigation is mostly sane.
And it works without having to file patches, run dev builds, or hack GTK internals.

That shouldn’t be a compliment.
That should be the minimum.

And it’s the only one that gets even that much right.

i3: A Tiling Dream That Just Got Shattered

i3 was the only tiling window manager that had real promise for blind users.
It’s keyboard-driven.
It’s predictable.
It worked well enough with Orca to be usable, and in some cases, better than GNOME.

But then came Orca 47.
There was a major refactor to how Orca handles keyboard events—something that absolutely needed to happen.
The old code was brittle. The event handling model was broken.
It was the right thing to fix.

But now?
Some applications under i3 emit “window grabbed” events on every keypress.
And Orca now dutifully announces each one.
Every. Single. Time.

You type? Orca announces the app.
You backspace? It announces again.
You navigate? It just keeps going.
It’s unusable.

People noticed.
Everyone noticed.
But when everything is broken, triage becomes an act of despair.
This bug isn’t ignored.
It’s just buried under everything else.

“We Know It’s Broken. We Just Can’t Get to It.”

This is the real hell of Linux accessibility:
We’re not waiting on unknowns.
We’re waiting on maintenance.

Take this one:

• Set Speech Dispatcher to use espeak, language en-gb.
• Feed it an emoji.

It says:

“Up. Up. Up.”

This bug has been around for years.
It’s fixed. It works on my machine.
But most distros still ship the broken version.

Because:

• The patch wasn’t backported.
• The build flags weren’t set.
• The package is out of date.

And so we wait.
We wait for fixes that exist.
We wait for patches that are public.
We wait for people to ship what already works.

We’re not asking for miracles.
We’re asking for working builds.

Maybe the next post should be titled:
“It Works On My Machine: The Final Words of Every Linux Accessibility Bug”

Debian: It’s Good… If You Know the Secret Handshake

To its credit, Debian is one of the few distros that actually gets installer accessibility right.
The installer has been accessible for years. Press s at the bootloader prompt and it’ll start with speech.
If your machine still has a PC speaker, it even beeps to let you know it’s ready.

Of course, most machines don’t have a PC speaker anymore, so if you miss the prompt—or didn’t know about the s key? You get silence.
But to Debian’s credit, that is documented. The wiki tells you how to start it. Once you do, it works.

The installer speaks.
The login prompt speaks.
You get Braille if you have a display.
Speech continues after install—because the installer sets it all up properly.

That’s rare. That’s good. That should be the baseline.

But here’s the rub:
Debian’s packages are ancient.
Orca improvements from years ago? Not there.
AT-SPI updates that fixed real focus tracking bugs? Not present.
Even if you manually build a new version of Orca, you’re still stuck with the old core libraries—so it still breaks in weird ways, and you’re right back where you started.

So you do what a lot of us eventually do:
You build the whole thing yourself.
Or—if you’re like me—you run something even more cursed.

Bedrock Linux: Frankensteining the Linux You Actually Want

When the package problem gets bad enough, there’s only one thing left to do:
Steal packages from other distros.

Bedrock Linux is a meta-distro. It’s not really a distro at all. It’s a way to run multiple distros at the same time on the same system—cleanly, natively, with actual package managers from each.

Bedrock uses something called strata—basically, root filesystems from other distros (Debian, Arch, Alpine, etc) that all coexist in your system.

• You install Bedrock on top of Debian.
• You “import” Arch as another stratum.
• You install Orca, AT-SPI, and whatever else from Arch.
• And now you’re running Arch accessibility tech on top of a stable Debian system.

You want stability from Debian? You got it.
You want fresh speech software from Arch? You got that too.
You can even run GNOME from Fedora and Firefox from Ubuntu. At the same time.

It sounds like magic.
It also sounds like:

• A bootstrapped unionfs overlay nightmare
• A dozen mount namespaces
• Real-time DNS resolver juggling
• And a complete loss of sanity if something breaks

So yes, it works.
I use it.
But I’ll probably write a post later called:
"Why I Run Bedrock Linux, and Why You Shouldn’t."

Because once you're running brl import arch and patching ld.so.cache by hand to make sure your screen reader sees the right libraries from the right distro, you’ve gone too far.
You're not just using Linux anymore.
You’re wrangling demons.

There’s Hope—But You Have to Squint to See It

There is one glimmer of actual promise:
NixOS.

It’s not accessible by default. Not yet.
But it’s built differently. And that matters.

You define your system as code.
You can pin package versions.
You can rebuild the exact same setup on another machine.
You can roll back changes if something breaks.
You can guarantee that your screen reader is installed, configured, and enabled every single time.

That’s the future.
That’s how we make accessibility reliable.
Not with fragile scripts or one-person distros—but with reproducible systems that treat configuration like infrastructure.

But NixOS isn’t ready yet.

• It’s too complex.
• It assumes too much knowledge.
• Its global configs are intimidating.
• Its tools aren’t accessible.
• It doesn’t speak on boot.

It’s promising. But right now, it’s another power tool—and not something a blind user can just pick up and run.

This Is Only the Beginning

This post is just the beginning of the series.

Coming next:

• Post 2: The Audio Stack Is a Crime Against Accessibility
• Post 3: Speakup, BRLTTY, and the Forgotten Infrastructure of Console Access
• Post 4: GRUB, Encrypted Disks, and Why Blind Users Get Locked Out
• Post 5: Orca, AT-SPI, and Why Nothing Tracks Focus Properly
• Post 6: glibc, Userland, and the Incompatibility Beneath the Surface
• Post 7: The Kernel, the Console, and the Accessibility Tech Everyone Forgot

Because Linux isn’t hard because it’s powerful.
It’s hard because it doesn’t care.
It doesn’t ship accessibility.
It doesn’t maintain it.
And when it breaks, it leaves you in silence. Alone. Locked out.
And we’re done pretending that’s okay.

And the Worst Part? I Can’t Even Recommend It.My partner wants to switch to Linux.

She’s frustrated with Windows.
She wants something leaner, faster—something she can actually control.

She asked me: should I do it?
And I didn’t know what to say.

Because if I say yes, I’m lying.
If I say no, I’m gatekeeping.
And if I tell her the truth—that she’ll need to patch PipeWire configs to get audio on a second TTY, that Orca might not speak after login unless she scripts it, that even emoji might get read as “up up up” if Speech Dispatcher pulls the wrong build—I’ll sound insane.

But I’m not exaggerating. I’m living it.

And sure—I could fix it.
I could patch it all for her.
Hell, I’d probably enjoy it.
I love computers.
I love Linux.
I love proving people wrong when they say “that’s not possible.”

But she doesn’t want that.
She doesn’t want a system someone else builds.
She wants to do it herself.
She wants it to work for her, on her own terms.
And Linux—right now—will punish her for that.

So no. I can’t recommend it.
Not yet.

And that’s what breaks my heart.

---

A lot of people will say it’s not a big deal.
That there are more important things in life.
And sure—there are.
But this? This matters too.

Because when we got together, she didn’t care about any of this.
Now?

When I’m stuck debugging speech lag or some failing audio pipeline,
she says things like:

“Try a FIFO pipe.” “Check for memory leaks.” “Are you calling malloc() wrong?”

And the other day, when I was screaming at Git—like we all do—I sent her the Git docs as a joke.

I expected her to skim it, laugh, and say “what the hell is this?”
And I’d say yeah, it’s stupid. It’s built that way. I’ll fix it later.

But instead?

She started reading.
She looked up revert.
She looked up debug.
She looked up blame.

Because she wanted to help.
Because she wanted to understand what I was fighting.

And now that she wants to switch to Linux?
Now that she wants to take control of her own machine?

I want to give her something worthy of that trust.
I want to say yes, absolutely, come in, this is where the real tools live.

But I can’t.
Not yet.

Because the system still punishes you for trying.
Because it’ll lock you out silently and leave you with no speech and no logs.
Because the best I can offer her today is scripts, and breakage, and prayers.

And she deserves better.