Can blind people code on linux?
Created: 2025-02-13 23:05:19 | Last Modified: 2025-02-14 17:32:39
This was from a reddit discussion about wether it's possible to use linux and code while blind. Naturally, my response got a little overzealous. I'm keeping it here for future reference.
skelly2611 wrote
I'm just looking for some opinions on what the best programming environment is. ... So my question to yous is, what is the best shell for developing, what is Linux like with a screen reader and what screen reader could I use because I'm currently using NVDA. Anybody I have asked about using Windows CMD has said its pretty terrible,I have also considered mac but most of my course is taught through Linux so that wouldn't be super ideal either Any and all advice is very much appreciated, thanks
Fully blind here, been using linux to write code for many years. tldr: Yes, It is absolutely possible and even comfortable, though I wouldn't recommend it to a non-technical person. I can't compare to windows as I've never used it with a screen reader. Here's what worked for me on linux:
I use arch linux. The default bootable image has blind accessibility built-in (see arch wiki for instructions). You might need help configuring the BIOS, but this is usually a one-time thing. Not sure about other distributions, but back in the day I used ubuntu and that was also fine.
Basic accessibility in linux is achieved through a kernel module called espeakup. This uses the espeak-ng TTS engine, which is ancient, but works and is free. Because this is kernel level accessibility, it allows you to operate a machine even without any desktop environment. It will even read out boot messages. This can be very useful for developers.
You can then use gnome with orca for a desktop environment as others have mentioned. This uses the speech-dispatcher infrastructure behind the scenes. espeak is the default, but the speech-dispatcher can work with many engines and better voices are available (e.g. voxin voices by oralux). I use orca to browse the web with firefox and pretty much nothing else, except the occasional GUI application like OBS or libreoffice.
For the rest I use emacspeak. This is based on emacs, an ancient programmable code editor. The emacspeak project has speech and blind accessibility built into every facet of emacs, and it is easily extensible. emacspeak has its own TTS framework. Last time I checked, it used espeak by default on linux, though I have an experimental driver to make it hook into speech-dispatcher on my github.
I cannot overstate how powerful emacspeak is. It is much more than a code editor or even IDE, it is a desktop environment in its own right. I read emails, run several shell instances, use git, organize my life etc. all within emacs. I adapted this to my own preference and ability and it has made my life much easier. I cannot envision going back to regular GUI coding environments.
Now, this won't be for everyone, but if you are a programmer and are technically inclined you might give it a shot. Feel free to reach out to me if you want more advice.
meghap wrote:
I'm trying to imagine doing all this at the command line. I used to use a text editor alone, for coding, and moving to VSCode has made life a lot better. Autocomplete, reviewing where things are defined, syntax checking, searching across the entire project, typing to find a file, and more have all improved my coding experience immensely. How would this work under Emacs?
So let me preface this by saying that your VSCode setup sounds really cool. If you have adapted to a development environment, you and your tools are working in harmony, and it gets the job done, then there really is little reason to switch. This is true for sighted and VI people alike. There's no prizes for using emacs etc (though we do sometimes get special menus at bars).
Now let me try to answer some of your specific questions.
Emacs has full IDE capabilities, including code completion, jumping to definitions, syntax highlighting, etc. This usually works through so called major-modes that are associated with certain programming languages. These will rebind your keys for specific functions associated with that mode and change the display of text. That gets you the basics out of the box. For functionality that is specific to your project, for instance autocomplete with hints for the type signatures of class methods, you usually need further packages specific to the language. How this works has varied over the years, nowadays it usually involves setting up and connecting to a language server. This sounds scarier than it is, especially for the popular languages. Out-of-the-box Emacs also has a package manager to help you out.
Taking a specific example, let's say writing python code. I hit C-x C-f example.py to open a new python file, putting me in python-mode for that buffer. I write some code. Syntax is highlighted by font-lock-mode (a minor mode of which many can be active). But that's useless since I can't see it. Emacspeak further adds voice-lock-mode, which means highlighted text will be read out by a different voice, or the same voice in a different pitch. Or at least it could, I disabled this since I've been writing code for a while and basic syntax isn't something I need information about anymore.
I write a class and some methods. As I navigate, indentation level is read out by a voice saying a very fast 'indent 4', or 'indent 8', before reading the entire line. This is something I do want to know, especially in python, except when I don't, so I can toggle it with C-e d i.
Now I write some hairy nested dictionary comprehension. Think lots of nested brackets of different types. Emacs will highlight matching brackets, emacspeak will automatically speak out the corresponding opening bracket (along with context) as I insert new closing brackets. It also alerts me if brackets don't match. You didn't askk about this, but this is a life saver for me and I hope it illustrates the beauty of emacspeak.
Now I need to move to some other function. Navigation works on a per character, per word, per logical expression, and also per function/method/big object level. So I e.g. move forward one character with C-f and jump to the next function in the buffer with M-f, and so on. Using C-s to quickly search for a string is also something I use to just move around, along with C-< and C-> to jump to the beginning and end of a buffer. Other times I just fold up different indentation levels with C-1, C-2, and so on and move up and down lines with C-p and C-n, just because I feel like it. I use jedi-mode for python, so I can also put my cursor on an object with semantic meaning, like a function or method, and hit C-c . to jump to its definition. Hitting C-c , will jump back. This works across files and is aware of my own projects. During all of this, my hands never leave the alphanumeric keys.
Now for documentation I can, also thanks to jedi-mode, get function or method signatures spoken out as I type the name, along with types, and variable names. I don't always want this though, as it's too much audio clutter. So I turned it off and simply get the same by hitting C-e x to read out the minibuffer by emacspeak, which continuously displays the signature. Jedi also takes care of autocompletion, which btw is a universal emacs thing and is largely responsible for the self documenting nature of emacs. This works out-of-the-box but can also be enhanced with e.g. company-mode.
If I want to search across the whole project for something I usually go to the terminal, which is two keystrokes away with C-c and honestly just grep and use various shell tools. I'm sure you could also use jedi for this, but I just never bothered to bind those keys. The whole point of using emacs is I can adapt my workflow to use exactly the tools that I want. I also have various other shells, bound to several registers (reachable via C-x r j and a letter), which is a whole other topic I won't go into. One of these will have the python interpreter, where I can test things out. I like the REPL workflow where I can just evaluate expressions from buffers, at least for languages that support it. In my experience haskell, python, and lisp have excellent support for this in emacs.
When I'm done I'll usually want to commit my changes to a git repository, which I can do using magit with just a couple keystrokes by doing s to stage and C-c to commit in the magit status buffer, which then let's me write a commit message within emacs. Of course, I can also just C-c and use git from a shell.
If any of this breaks or I need to use different packages that aren't accessible out-of-the box, I know I can help myself because everything in emacs is a function: I can simply define advice around the function to make it speak out whatever I want using emacspeak functions. I have done this on many occasions.
I can go on and on. tl dr is you can make all those things you mentioned work in emacs, and make them be accessible via emacspeak. Will you have to endlessly fiddle with things? Absolutely. But I hope I could get across that when you go the emacs route, that's the whole point - you have the power to change anything you want. I've been using emacs probably since I was 19, when I could still see. All the stuff I mentioned I added step by step. Emacs sort of grew alongside me over the years, and my emacs is problably not like other people's emacs. Like a custom forged samurai sword, it gained some cracks and blemishes, but it fits my hand perfectly, and anyone else wielding it would probably cut themselves.
My friends somtimes make fun of me for using ancient technology from the 80s, saying vim is more popular, and emacs will be abandoned and so on, but I think this is foolish. Emacs is not a text editor, nor a code editor, nor an operating system. Emacs is an idea, and as such it can never be destroyed. Even if you traveled back in time to kill Richard Stallman and prevent emacs from existing, it would not matter. Whenever you write code and you think to yourself "Mmh. This could work better." you are reinventing emacs in your mind.
For this reason I am also not a fan of comparisons and competition between editors. It's apples and oranges. If VSCode works for you, that's great and you should probably keep using it. Now, of course, if you want the special menu at your local bar, you know what to do.