Having read many posts by blind programmers across different communities, including AppleVis, I would like to draw attention to something that many of you may already know, but that still seems to be underestimated.
1. Integrated Development Environments based on graphical user interfaces have become extremely complex. Even many sighted developers struggle with them, and some of the most experienced developers still prefer programming in an ANSI terminal environment.
2. Graphical user interface applications are often difficult or impossible to test thoroughly as a blind developer, which makes them a less attractive development target.
3. Terminal-based computing is purely symbolic and text-driven, with a predictable and linear screen layout. This makes it a natural fit for blind users—not only for programming, but also for everyday tasks such as email, communication, and system administration.
Linux is probably the strongest platform for this style of work. It can run on a Raspberry Pi (which I personally recommend), or be used on macOS or Windows via containers or hosted systems.
Terminal-based computing and programming certainly involve a learning curve, but many users find the effort worthwhile and empowering in the long run.
In this spirit, I have prepared a Braille-first, terminal-only Linux environment that may serve as a starting point. It is open source and free. Being based on Debian Linux, it allows users to easily install additional software for programming or other purposes as needed.
Project page:
https://github.com/stwelebny/beaver
Beaver is not an operating system itself, but can be installed after you already have setup Debian Linux.
Comments
Not a silver bullet
I have a very strong Linux background dating all the way back to early 1998 when I had the crazy idea of downloading the RedHat Linux 5.1 CD image (currently known as Fedora) over a dial-up connection, got involved in kernel development in the early and mid-2000s during the days of Linux 2.4 and 2.6, and with the exception of gaming, which I had a dedicated PC with Windows for, all my computer use was on Linux. I was one of the first people to join the compositor craze in 2006 with Compiz, used Gentoo for most of my sighted days, and only switched to macOS in 2011 when my vision began to deteriorate. Since then I kept using Linux on VPS hosts, containers, Raspberry Pis, you name it, but never again on the desktop, because the days in which I had fun recompiling the kernel to add support for a Wi-Fi driver, or patching power management code to make some buggy drivers wake back up from suspension, are long gone. Also and since I'm not congenitally blind and lost my sight well into my adulthood, I never felt much need to use Braille, which I did learn in rehabilitation but never actually practiced, and I don't think Braille is particularly useful for coding.
As a speech synthesizer screen-reader user, while I agree that command-line interfaces are vastly superior to graphical interfaces, my opinion flips completely when it comes to other kinds of text user interfaces with graphical user interfaces, so I run from console editors like the devil, and whenever I want to edit something on a remote machine, I just install
rmateon it, which is a Ruby script that makes it possible to use TextMate over ansshtunnel to edit remote files from the command-line as if they were local, and always try to learn about available command-line invocations that can help me avoid all kinds ofncursesinterfaces.Text user interfaces
Try some of those fancy TUI's, with animated spinners, or those Python Terminal prettifyer libs, and you'll see why the Terminal still isn't safe from the sighted's need to visualize, verb, everything. That being said, it is still, at it's core, the most accessible input output system. And that's also why AI's work so well too.
Thank you for this
This is really interesting.
Please forgive my foolishness. I'm assuming I can use something like parallels to set this up? What you've created is like an overlay for the linux OS, is that right?
Only one problem with code editing with VO in gui
Seems that virtually all code editors from cot editor, text mate , vscode, getbrains... when we do command left / right arrow on an indented line (which would be the case most of the time :) ) vo unreliably speaks either half the line above or below it. I think this does not happen in xcode. This drives me insane and isthe reason why I am trying so hard to learn emacspeak . How have you overcome that? Habbit (like all macos accessibility issues? :) )? You hinted many times that all these are due to nstextview... From a user side it seems that no work around is possible? I tend to actually use my braille display for coding on mac only for this, or I just switch on my windows laptop or vm inside parallels.
VIM doesn't work at all on most macs I have tried but for this one guy who is lucky, there is an old thread of mine on this topic here about a year or two ago.
Stormux and arch linux is the only low friction way I've found on my raspberry pi to use vim, and the sad thing is that I loove vim so much. I guess this thing can work on all arm chips so maybe could try to virtualize it on mac? But a linux vm on top of an almost linux ish os just for accessibility is disgusting for me.
As much as I dislike it, my computer science program is completely into microsoft and code/text editing is uncomfortable in guis on mac, at least as a daily driver for me despite three years of experience with the mac.
Terminal itself is great though and I am happy each time I use it!!!
And to @onetrickpony
I haven't tried this yet, but 11/10 on the idea! I was hard of hearing before so can completely relate to this more than most probably.
@Doll Eye
Not foolish at all — that’s a very reasonable question.
Yes, you can use Parallels (or Docker) to run Linux on a Mac. In that case also BEAVER runs inside a standard Debian Linux system. You’re still dependent on macOS + VoiceOver. Braille is then mediated by macOS, not native Linux.
BEAVER is not an overlay in the graphical sense. It’s a set of packages and conventions that configure a Linux system terminal-only and Braille-first, and to include a small, curated set of tools for everyday tasks (mail, web, social, AI, etc.).
So depending on the setup, you can use BEAVER in a few ways:
• On a Raspberry Pi, as a dedicated physical Linux system
• In a virtual machine (for example via Parallels)
• In a container or hosted Linux system, accessed over SSH
BEAVER doesn’t replace Linux; it builds on it and keeps everything text-based and predictable.
Some words on editors: do not look for integrated development environments (read also the comment of @Devin Prater). Linux is an integrated development environment. You can start with nano. And then I recommend to learn vi, even if it's hard in the beginning.
Mail, Mastodon and ChatGPT need some configuration.
BEAVER - "Builders Engineering Accessible Versatile Efficient Realms".
Experienced Linux users probably won't need to install BEAVER. They will already have things in place.
Indentation in TextMate
I've read your complaints about that specific quirk quite a few times, yes, but while I know what you're talking about, it's not something that interferes even mildly in my workflow, so honestly I never found it to be an issue, not even a minor one. Usually whenever I want to move to the first non-whitespace character in TextMate, I just press Home or Command+Left followed by Option+Right, with the latter not being required in Xcode since it already assumes that you want to move to the first non-whitespace character by default.
I don't even think that the problem is
NSTextViewin this case, even if I said something different at any point in the past, my current opinion is that it's related to TextMate snapping the character to tab stops matching your indentation preferences on the left most side of every line, and that ends up confusing VoiceOver as it tries to figure out what kind of caret movement you triggered. The reason why it doesn't happen in Xcode is likely because Xcode doesn't do this snapping.@João Santos
Thanks you :) as always.
Wonder...
Is this a little like the Adriane Knoppix setup, a text desktop?
I'm not a programmer, but I just wondered, because it used some sort of voodoo of calling up part of Gnome when launching Firefox and other graphical programs that also launched Orca, all without having to start a full GUI. LXDE back when I was using it.
Edbrowse
I agree about Curses programs and other TUI programs often being hard to use. For my editor I use Edbrowse, which is not a TUI but rather an interface similar to a shell like Bash. Just pressing enter outputs the next line in the file, a period outputs the current line, dash outputs the previous line, etc. Every command that moves to a new line of the file outputs that line, and there are commands for outputing a range of lines, but the entire file is not displayed on the screen and it only displays what you tell it to display. There are commands for marking the current line and going back to marks, searching for regular expressions, search and replace, etc, and this is only the beginning because you can combine line ranges with commands, and have it, for example, replace a string of text from mark a to mark b. You can also have multiple buffers open for different files and copy text between them, read shell command output into buffers and pipe buffers into shell commands, etc.
It even has a web browser, with the same interface as the editor but with commands for activating links, filling form fields, etc. It does not support advanced Javascript, so things like Google search, Google Docs, etc do not work, but it is a good browser for reading documentation and things like that. It also has an email client for both sending and receiving emails, and an IRC client. This kind of interface seems better for speech than Braille but I use it a lot with Braille as well, and I use it for almost all the programming I do.
Raspberry Pi 500+ and BT Speak
I agree Raspberry Pi's are good devices for terminal Linux and for Beaver. I think two devices in particular to look at are the Raspberry Pi 500+ and the BT Speak. The Pi 500+ is a QWERTY keyboard with a computer inside it, and it has 16 GB of RAM and a 256 GB SSD. It does not have a battery or speakers, but you can power it off a portable power bank and connect headphones with USB or Bluetooth, and a Braille display as well. The Pi 500+ itself is $200. There is also the BT Speak, which is based on the Raspberry Pi 4, so the CPU is less powerful, and has 8 GB of RAM and 32 GB of internal storage, but it is significantly smaller than the Pi 500+ and has a Braille keyboard, a battery, and built-in speakers. It has its own custom applications and user interface, but it is based on Raspberry Pi OS and you can easily access the terminal, so you should be able to install Beaver on it. It is significantly more expensive though.
Unintuitive installation
I'm not going to create an issue on GitHub about this since I do not consider myself the target audience, but I did install this in a Debian container and found the process to be rather convoluted for new users, especially the character set and font selection steps, which are both presented as lists with tab-separated columns that don't work very well with screen-readers.
For starters I'm on macOS, and although I do have a bunch of Raspberry Pis that I could use to run this, I decided to just go ahead and try it on my own Mac, using the Docker container front-end on CoLiMa, which is itself a container back-end on top of LiMa which is an implementation similar to the Windows Subsystem for Linux on macOS. The Docker front-end, CoLiMa, and all the required dependencies were already installed and updated on my system through MacPorts so that part of the setup is omitted, but the rest were the steps I took to get this installed. I did not run anything after the installation since that was not the point, plus things would need to be configured adding extra complexity to the process.
So first I just started CoLiMa, which is usually always running on my system as its 128GB of RAM are plenty for pretty much everything, but for illustration purposes, I did stop the service and then started it again to get the terminal output:
Then I spun up the official Debian container image using the Docker front-end and got the root shell inside the new container:
Inside the container, I upgraded the package metadata:
Then I installed
curlso that I could actually download a Beaver release with all its assets:Then I downloaded Beaver and its assets:
Only at this point was I finally able to begin installing the downloaded packages, whose output I cannot paste here because it didn't even fit my terminal buffer, so I'll just leave the command prompt:
My suggestion to the original poster is to post a shell script to GitHub in the project repository or as a gist, and provide a one-liner command to download and run that script much in the same way Rust is normally installed, as well as a Dockerfile to automate the generation of a container image with everything ready to go for those like me who'd rather just use a container, with instructions on how to set up the system using CoLiMa or any other back-end, with a front-end that doesn't even have to be Docker itself, to generate the container.
Editing to mention errata and add another suggestion.
First let me correct myself, since in the Docker command prompt above, I used the
--labelswitch when my intention was to use the--nameswitch to name the new container. The command worked because the--labelswitch does exist, which is why I did not notice that mistake, but its function is to actually define key-value pairs of metadata, not name containers.Secondly, I suggest creating a git tag named
stable, which as its name implies, should always refer whatever commit is currently the latest stable version, as that allows installation scripts and instructions to use that tag instead of specific version tags and thus be less version-dependent. At the time of this comment, thestabletag should probably refer the same commit as thev0.1.0tag, or if that's not considered stable due to being a pre-1.0 version, then maybe the tag should instead be namedexperimentalor something of that kind.