I am very curious and want to help to make Linux more accessible.
I wrote with some people and got some insights:
- everything text, like a read-mode-only browser or a plain Terminal is best for TTS engines.
- TTS engines are difficult, some are really good but need many resources, some are worse but save resources
- TTS needs to be optimized to be really fast in some cases, to keep up with the speed
- some apps are better, some are worse, but probably most apps dont really suit blind people, as the whole GUI concept makes no sense
I am really curious. How would it be best for you, braille vs. voice, voice input vs braille vs. gestures?
What apps do you find best, how do you browse the web, find media to listen, how do you use Document editors and what purpose do they have for you?
Thanks a lot!
Preface: I’m not blind. I’m aware you’ve not asked for solutions, I just can’t help myself. Sorry!
pipewire+wireplumberand have had no issues. Probably because my needs are simple. What I do want to point out, though, is that I’m launchingpipewireandwireplumberfrom myshell rcfile before my window manager. I’ve tried playing sound from attyand it worked, although that was the limit of my testing.fstabbreaking boot it works the same. All you need to do is add anofailoption to the volumes you don’t need for boot to succeed.aptdoes not appear to support hooks. All I can suggest is create a wrapper script that runsI do wonder if creating a Gentoo distro focused towards accessibility would help get some more feedback from the most technical and courageous users.
I have no problems with solutions. Thanks for helping me, and for helping blind searchers in the future who want to give Linux a try. My point here, really, was that the defaults are bad. When you configure drives to mount via the GUI, it doesn’t set nofail. I wasn’t even aware that was a thing. But never the less, a drive that mounts only to serve as a fileshare for Samba shouldn’t prevent everything from coming up by default if it can’t mount. The assumption behind every design decision made by the entire Linux boot process assumes that if something fails, you can see the screen. Similarly, when you initialize sound from your shell RC file, it means blind folks can’t log in via the TTY, because we don’t have sound at that point. Sound needs to be moved out of userland if we’re ever going to have a fully blind accessible Linux. Not only do I need sound to get logged on in the first place, without sound, the system can’t tell me about any errors until after I log in.
Ah, that time I magnified the screen with my phone to get my NAS back up. Conversely, that time I did unspeakable things to my Mac and got it restored just fine.
Yeah, it’s not about the specific issues, it’s about assumptions and lack of out-of-the-box accessibility.
Fair points. All I can say is that Linux was built in a way to be commanded. It makes no assumptions, fails on error. In general that’s an amazing thing and really what majes it great, but I appreciate the fact it gets in a way of accessibility specifically.
I completely agree. It wasn’t built to be a desktop OS.
But it does make assumptions. It assumes I can see the monitor and read printed text. I’d have no problem with it failing on error, if that failure always made sound. There are BIOS firmwares that can play mp3 files, and DOS could make noise via the PC speaker, for God’s sake. There’s no excuse for Linux’s ableist assumptions.
I’ll stick to what I said before - it doesn’t. You can command it to make noise, but it has to be an active decision.
But you don’t have to command it to print text on the screen. That doesn’t need to be an active decision. Your assumptions are still showing.