How would your (Linux) Desktop be structured to be perfect?

Linux has no comprehensive, standard, accessibility API that will work cross-window manager, cross-desktop, and cross-platform.

And with Wayland it's even worse.

Preface: I'm not blind. I'm aware you've not asked for solutions, I just can't help myself. Sorry!

• I'm running Gentoo and have switched to pipewire+wireplumber and have had no issues. Probably because my needs are simple. What I do want to point out, though, is that I'm launching pipewire and wireplumber from my shell rc file before my window manager. I've tried playing sound from a tty and it worked, although that was the limit of my testing.
• I'm using OpenRC, but in terms of fstab breaking boot it works the same. All you need to do is add a nofail option to the volumes you don't need for boot to succeed.
• I cannot say what's going on with the kernel module breaking and apt does not appear to support hooks. All I can suggest is create a wrapper script that runs
  • apt-get update
  • apt-get upgrade
  • rmmod speakup
  • insmod speakup
  • systemctl restart speakup
• No comment about API, that's beyond my understanding.

I do wonder if creating a Gentoo distro focused towards accessibility would help get some more feedback from the most technical and courageous users.

Do you know alternativeto.net ? Is it accessible? I would like to request a "blind" category, or would you prefer a better name?

Thanks a lot for the details!

Yes a kernel module sucks, these never work. This would be a point for immutable distroa though.

If you dont know the concept, here is what it looks like

• on a regular Linux System, your package manager fetches the resources from a repo and updates your system on its own. This gives the easy freedom to mod everything how you want, but like you mentioned, things can break
• on an immutable System, most namely Fedoras Atomic spins (the new name including all Desktop variants and hopefully soon a blind variant) the system is maintained on a server, built there and many people can look at it and see if something breaks
• your local system can update automatically, and copies the exact system on the server. This is done using OSTree, basically git for your filesystem
• if an update prevents your system from booting, you can reboot and choose the previous version. Poorly this is not default on Fedora for "flickerless boot" (as the screen would go black and then show the grub menu) which is completely useless and should need to be deactivated on a blind Edition.
• so you can roll back to a working system, if problems like these would happen. Always one previous version is kept.
• but often the system on the server (ostree remote) would not build successfully, as its controlled using CI tools and all, so you simply wouldnt get an update until that is fixed.

In such an edition a community could get together, include all the software that works best, preset all settings, and manage a distro that works.

I dont know how well Flatpak and other things work though, which seems to be a good solution to have a not-breaking system.

To your point of sound being bound to a working userland: this is very bad of course. It may be circumvented by using a stable release of some Desktop that never breaks, like GNOME. But this sounds like needing a bigger solution.

To the systemctl thing, I experienced something similar. You may add the "nofail" tag to every drive, to avoid that boot error. It sucks a lot, true.

Standardisation has its value, the same with paid software, thats true.

Hello, a daily Linux blind user for several years here. @fastfinge I would like to respond to some of your points, as I find them somewhat misleading.

Sound never, ever works: Alsa, pulseaudio, pipewire…some apps require one, some apps require the other, and they don’t work together at all well. Plus sound is considered part of the userland desktop environment. So if there is some problem preventing the GUI from launching and dropping me into a shell, I can forget about having any accessibility what-so-ever. We’re what feels like decades away from having the advanced features that CoreAudio on mac or WASAPI on windows offer (audio ducking, first-class support for multiple soundcards and routing audio from different apps to different outputs easily, per-app volume adjustment, loopback recording, low latency, any kind of spatial anything, etc.).

My experience is quite different. Regularly tracking the blind Linux mailing lists and guiding newcomers on getting their systems accessible, problems with audio are actually very rare these days. Mainstream distros like Ubuntu come prepacked with a bunch of drivers, ensuring great compatibility. From time to time someone appears with sound problems, but most of the time it turns out to be a corrupted installation image rather than actual audio issue. I don't remember anyone who wouldn't be capable of installing the system because the audio wasn't working. Alsa is a kernel module responsible for playing sound, PulseAudio is a software mixer built on top of Alsa providing more civilised audio interface for applications, PipeWire is a drop-in replacement for PulseAudio bringing some fresh wind to the field, mostly improving bluetooth headphones/speakers compatibility, but also improving latency etc. I don't see how these could get in comflict. PW and PA shouldn't occur on a single system installation, while both are designed to work with Alsa. For applications, it doesn't really matter, most of them had been developed in times of PA, and PW is backward compatible with it. I've fiddled with many applications through the years, and didn't see a single-one that would have audio problems. As for audio effects, there are very popular PulseAudio modules, PipeWire modules you can use for various effects like noise cancellation, audio filtering etc. I didn't play with them too much because I didn't see any added value also in Windows audio effects. I once applied a noise-cancellation tweak trying to improve the quality of my laptop's internal mic, but well, that thing has so bad sound I eventually decided to stream the microphone from my smartphone to PulseAudio through ADB, and it worked really awesome! And it's remained working also after switching from PA to PW not needing any changes. So much for audio flexibility and compatibility. Even more interesting effects can be achieved with systems like Jack, but being just an average user in audio terms, for me it's been never worth setting up. The things you mention like working with streams of specific apps are perfectly possible. Perhaps a more straight-forward interface wouldn't hurt, but other than that, it works, whatever. :D There had been some controversial topics indeed in the past, like when Alsa devs decided it would be funny to make the audio volume 0% by default and having it muted as well, what didn't get really appreciated by the blind community. :D But then, on Windows screenreaders are applying workarounds for years to prevent soundcards from auto-sleeping, otherwise the effects are really crazy, with the funniest part being they don't even work 100% of the time, I had computers where I needed silenzio anyway. So, these things are by no means unique for Linux, I see it just as the general kind of things we're used to be dealing with.

meaning I have absolutely no recourse other than “get a sighted person to come to my house and fix it” because I did something as simple as swap a drive.

As a blind student using Windows, I was regularly calling my classmates to read me the screen, because I did something as simple as trying to turn my computer on. Actually, Windows got the ability to activate the screenreader during system installation just few years ago with Windows 10, Linux could do this long before. And while on Windows I had been pretty stuck, Linux seems way more flexible to me in this regard, at worse I can boot up a live distribution and fix things from there, I don't remember the last time I booted a Windows Live image. :) That's not to negate your point, the situation indeed could be better and there are distributions like Slint trying to achieve this. Though, I think it's also worth mentioning this is a wider topic than Linux, just for how long have we been discussing UEFI accessibility, grub accessibility etc. These problems are related to all blind people, and of all the systems we have today, Linux gives you the most power to do something about them if necessary.

Linux has no comprehensive, standard, accessibility API that will work cross-window manager, cross-desktop, and cross-platform. In Windows or mac, there are clear guidelines that developers need to follow to create accessible apps. If an app is inaccessible to me, I can refer a developer to first-class, well supported and understood, API documentation telling them what they need to do in order to better interact with my screen reader. On Linux, that’s not so easy, meaning apps just never get fixed, because developers working for free just can’t be expected to figure it all out themselves.

Linux has at-spi, that's the universal accessibility standard equivalent to MSUIA on Windows. It's pretty well developed, works on any setup that has DBus, another standard thing you find basically anywhere, even sandboxing software like Flatpak or Snap respect atspi interfaces, meaning it's not some random thing supported by few demo apps, it's a full-fledged accessibility standard used by GTK, QT, web engines, Java, etc. It does have documentation, and even software for helping developers evaluate the accessibility trees of their apps. The argument that apps don't get fixed because devs don't understand atspi is something that... is not really the cause of the problems. Just compare with Windows. When was the last time you discovered an inaccessible app, you wrote the developer "Hey, your app is inaccessible, but there is this great, well-documented MSUIA thing you can implement and get it working", and the developer was like "Awesome, thanks for your feedback!" and made the app accessible? I wouldn't like this to sound rude or anything, because it's not meant that way, I just want to point out this is very lowlevel stuff that noone but accessibility experts understand, and it's a work beyond one person or even a small team without relevant expertise to make applications accessible using these APIs. Not even highly popular GUI libraries managed to implement it properly. Consider Java and QT, GTK never even bothered. While, that should exactly be the way for app developers to support accessibility, to use correctly their GUI frameworks, which should be responsible for handling MSUIA stuff. Many of them didn't really. That's why Matt Campbell started the AccessKit project, which is really promising in terms of cross-platform accessibility, he already improved atspi quite a bit and other changes are planned, see your other linked post. That's why I would say Linux not only has universal accessibility API, it's also one of the most open APIs we have these days.

Btw, quite a lot of Linux GUI environment is already accessible, as I mentioned I'm a daily user and things are really on a decent level, but things are just starting to move. It's not so long ago that KDE selected accessibility to be one of their main goals, and there's going really a lot of work into making that determination true. Cosmic desktop, the new environment of PopOS written in Rust, is building on top of GUI frameworks working on implementing AccessKit, and System76 committed itself to support the accessibility of the environment. A lot of development is happening in Orca, we're getting a lot of new features, refactors and bugfixes, improving the experience really significantly. Redhat has hired two people I'm aware of specially for accessibility positions, to work on improving GTK 4 and GNOMe DE accessibility, the work done by the accessibility teams has already shown up in both the environment and the framework. Wayland is a common scarecrow in the whole Linux world, not just the accessibility-one. But the reality is not that bad, there are few annoying minor things we're workarounding just now, like clipboard being available only to applications that have a window, making flat review copy not working (Orca come up with a feature similar to the Jaws' virtualisation to fix this). On one hand it's true it is annoying, right. But on the other, when I realise any Windows program is capable of freely reading the clipboard without any special privileges, and this has already been misused in the past for stealing money by swapping crypto adresses, I'm not sure it's that clear what's actually the inconvenience.

1/2