Getting a decent VPS is pretty cheap. Email is the enormous problem. Even if your VPS provider allows outgoing email, your IP address will be flagged and blocked by all mailservers everywhere for the crime of not being Google or Microsoft, or not having a full-time person working 24/7 to satisfy the people in charge of blacklists. You can pay someone else to send your email, but that’s going to cost you as much or more as the VPS you’re using to host your entire app.

The issue here would be that no two blind people have exactly the same needs. It sounds like this would prevent any customization at all. We all use different speech voices, at different speeds, etc. So a system where no settings can be changed just wouldn’t work.

It happens in a few ways. First, by examining the sourcecode when available. However, blind programmers talented enough to do this generally have paid, closed source work they’re busy with. Second, when a platform has accessibility API’s, it’s at least easy to get the outline of a system, and determine what’s not working. Third, of course, commercial grants for paid work. In the case of Windows, many corporations pay a lot of money to make sure Windows is accessible, so it can be used in schools, governments, and workplaces. This kind of money just hasn’t been invested in the Linux desktop ecosystem. As well, in a centralized closed-source system, it’s easier to force everyone to follow various coding requirements. In the case of Linux, who has the power to push through the infrastructural changes we’re talking about? Oracle/Gnome, I guess? But there’s a bunch of work the distros also need to do. Unlike in Apple or Microsoft, it’s not just a matter of getting the “CEO of Linux” (not a real position) convinced that accessibility matters and she should invest in it.

Or perhaps, better to rephrase as “first priority should be to have a system that’s as reliable for blind people as it is for sighted people”. In practice, that means that whenever text is printed to the screen, there needs to be a way for a blind person to know about it. Text to speech systems like espeak can run in kilobytes of memory and storage. The primary problem is sound support.

The second problem is maintaining this system. Right now, Linux is caught in a vicious circle. The system isn’t accessible enough for a blind person to use, so why would a blind person put in a bunch of work on it? The NVDA screen reader on Windows is an open source screen reader entirely created by blind users. But that only works because Windows is accessible enough that the tools blind people need to create and maintain software are accessible enough for us to use. What are the tools for creating these types of systems like on Linux? You mentioned CI tools. Currently, the leading providers of these tools don’t provide decent screen reader access to them, as far as I am aware. So now the tools for blind people on Linux need to be built and maintained by sighted people. From a practical standpoint, this just isn’t going to happen. Open source only works when people are scratching their own itches. It’s power is when people can build solutions for themselves. In the long term, an accessible Linux built for blind people by sighted people just isn’t sustainable.

I’ve only used it to browse briefly, so I don’t know if it’s fully accessible. But for what I’ve needed it for, it’s worked. “Blind” would be the appropriate name.

Before we can even think about some kind of desktop spin, there are massive infrastructural issues preventing me from using Linux as my primary machine. I run several Linux servers, so my experiences are based on my experiences running those, and my experiences stripping desktops out of Linux machines that had them when I didn’t want them to.

• 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.).
• Similarly, all of systemctl’s targets are set up really, really badly for accessibility. If one of the drives in fstab can’t mount, even though no core services depend on it, SSH won’t come up, sound won’t come up, networking won’t come up, 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. These days, mac systems can launch a full screen reader during system recovery. Windows isn’t quite as slick, but it’s close; it’ll do the best it can to boot and get me a screen reader, no matter how badly things are broken. Linux will just give up and die, assuming I can read the screen and type on the keyboard to fix whatever happened. I need the system to require, at least, sound support and a console screen-reader no matter what; if those things don’t exist, it’s the equivalent of the machine just showing a sighted person a black screen with no further info.
• The primary console screen reader, speakup, still requires a kernel module. If apt updates my kernel, it can (and does) kill the screen reader entirely.
• 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.

Until some of these basic problems get fixed, creating a fancy new desktop spin is just walpapering over basic design issues that will keep blind folks third-class users on Linux well into the foreseeable future.

Different but kind of related: try to avoid finding the “best setup” and over specializing in it. I started using the eloquence speech synthesizer in 1997. It hasn’t had any updates since 2002. But I got so good at listening to it at extreme rates of speed, that it’s now nearly impossible for me to switch to something else. I have to go through all kinds of silly nonsense to keep this ancient 32-bit synth running on modern platforms. If I had only forced myself to use multiple different synthesizers, even if I was slightly slower with each individual one, I now wouldn’t have this horrible lock-in. When I am finally forced to switch to something else, it’s going to slow me down for months or possibly years, because of how much I’ve over-specialized in understanding eloquence at over 800 words per minute, and how much of my workflow I’ve built around my ability to listen that quickly.

For those of us using screen readers, this is a way bigger deal. Honestly I probably shouldn’t use a bluetooth headset and a bluetooth keyboard for my banking. We focus so much on SSL/HTTPS and wifi security, but I wonder how much effort goes into wireless keyboard security? Not nearly as much, I’d bet.