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.
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.@JoĆ£o Santos
Have you ever used orbstack for virtual machines and containerization? If not, I assure you that you'll be pleasantly surprised by this solution :)
orbstack
Assuming that orbstack is the native paid solution that I think it is, then I'm likely not interested. Apple themselves released a Swift package optimized to do Linux containerization on macOS, so if my current setup with CoLiMa ends up becoming a burden, I'm a lot more likely to just grab that Swift package and build something free myself than to pay for someone else's development containerization solution. For fully blown Linux installations, Apple's native Virtualization framework already provides a fully blown virtual machine implementation with VirtIO virtualized hardware ready to integrate with any application, so even from that front I cannot justify the need to pay. However, if you believe there's something else worth paying for that is not covered by these solutions and that I might be completely oblivious of, don't just teas it, enumerate the relevant features.
@JoĆ£o Santos
Here is the information from their website:
OrbStack is a paid product now that it's no longer in beta. You must purchase a license for freelance, business, and commercial use.
* Personal use: free
* Business and commercial use: $8/user/mo
* This includes non-profit organizations.
* Educational use: Free licenses may be requested, subject to approval.
* Use for open-source development: Free licenses may be requested for non-commercial projects, subject to approval. Commercial open-source developers must purchase a license.
We hope that the performance, speed, reliability, simplicity, and potential cost savings of OrbStack will justify the price. Contact us if you have questions or custom needs.
Feature comparison
Feature OrbStack Colima
šØ Use Cases
Docker ā ā
Linux machines ā M3 or newer
Command line ā ā
GUI ā ā
Kubernetes ā ā
ā”ļø Performance
Fast startup ā ā
Fast network ā ā
Rosetta x86 emulation ā Experimental
š Efficiency
Low CPU usage ā ā
Low power usage ā ā
Dynamic memory ā ā
Native macOS app ā ā No app
š Ease of Use
Minimal setup ā ā
Simple UI ā ā No UI
2-way file sharing ā ā 1-way
SSH agent forwarding ā ā
No admin required ā ā
Auto-update ā ā
š¾ Network
IPv6 ā ā
ICMP ā ā
VPN compatibility ā ā
macOS DNS ā Limited
localhost forwarding ā ā
HTTP(S) proxy ā ā
SOCKS proxy ā ā
š¦ Containers
Host networking ā ā
Bind mounts ā ā
Volume file access ā ā
Image file access ā ā
Container domains ā ā
Automatic HTTPS ā ā
Extensions ā ā
ā Kubernetes
NodePort access ā ā
ClusterIP access ā ā
LoadBalancer IP access ā ā
Auto wildcard domains ā ā
GUI for pods & services ā ā
š§ Linux
Full Linux distros ā M3 or newer
Automatic SSH ā ā
Connect between machines ā ā
Fast x86 machines ā ā
CLI integration ā ā
Run graphical apps ā ā
@JoĆ£o Santos
There is a Dockerfile in /docker
My opinion stands
I did check out the website earlier because I did not associate the name to anything, which is how I recalled that it was likely the software that I thought, and my opinion stands. I don't see much value in paying for something that I can easily build myself using native and open-source Apple frameworks, and I'm not a heavy container user. If it was free I would be all over it, but I cannot justify paying for Linux containerization software, which is why I stay away from Docker Desktop itself.
I do develop containerized solutions every once in a while, and will start doing it more often soon as part of my own business, but the solutions that I work on are designed to be distributable, making it possible for my back-ends to linearly scale horizontally by automatically launching more containers in response to load, and not requiring huge swarms of containers running locally for testing. I also write a lot of highly optimized Rust code, which allows me to save a lot on cloud costs as the optimizations make each of my containers very resilient to heavy pounding. The graphical user interface is totally useless to me since I always interact with these things from the command-line, host networking is very useful but I think that's already supported by the Virtualization framework on macOS 26. The optimized kernel doesn't have a lot of value to me since my Mac Studio has more than enough resources to keep the virtual machine created by LiMa running all the time even when I don't need it, and even if the optimized kernel had value to me, the aforementioned open-source Containerization framework from Apple provides an optimized kernel itself. Even x86 emulation is provided by Apple's frameworks, however Rosetta is going away in the next major release of macOS so either someone else provides a fast x86 emulator or the only viable option available to everyone ends up being qemu which is quite slow and is also an option available in LiMa and thus CoLiMa.
RP setup.
Somebody suggested using the RP 500 Plus for this. Quick question, is there a setup guide? Last time I was considering getting one of these, this was on 400, somebody else saved me the trouble of asking on another blind forum and they were told that if you needed a setup guide, it wasn't for you. There used? to be an RP page for blind setup, some sort of org, but last time I checked their URL was either gone or gave a 404.
I keep kicking around the idea of grabbing one of these and a USB battery thingy to have a portable computer. But there seems to be little or nothing on setting it up totally blind and what little I did see suggests you're going to need sighted assistance. I can get that, but if I can do it myself, so much the better.
Asahi Linux?
I know this is an ongoing project but was watching a video about it earlier. Not sure where they[they've got to with it, but it did appeal on the basis of being able to use steam along with proton.
Is Asahi Linux viable for us screenreader users, both install and usage?
Sorry if this is a little off topic.
RP 500/400
@Khomus: Why not simply use the 400?
Because I don't own one?
I don't own any RP device. I was looking to possibly buy one. So I may as well get the newest one.
Braille is Certainly the Way
I agree that running Linux in a VM just to get Braille via BRLTTY is regrettably necessary, but there's just no arguing with the results, and at least you can still run proper server software on macOS, so you can often simply use Linux purely for remote SSH access to the same Mac. I have read many codebases using computer Braille under my fingers, and I wouldn't have it any other way. No. Not at all. There is no faster way to take in the punctuation of code, nor the indentation. And even with a single-line display, you get two-dimensional access to the screen, including VT text attributes that you need to track the highlight.
That having been said, if you want to use speech on macOS, at least benefit from VoiceOver at its best, which is plain stdio in Terminal, i.e. yes, learn and use ed (or edbrowse). There is still a lot of value in doing that. And, of course, you can install and use screen readers that rely on PTTYs, like TDSR, or complete speech environments, like emacspeak.
Setting Up the Raspberry Pi 500+
When I got my 500+ a few days ago, I was able to set up Raspberry Pi OS independently. When you pluh it in and turn it on, you can press Ctrl+Alt+Space to install Orca. You must connect it to ethernet first though, and you should have a USB audio device connected. You can get a USB to 3.5 mm adapter to use standard wired headphones. If you do that command after the OS has booted and with ethernet plugged in, you should hear eSpeak say "installing", and in a minute or so the Pi will reboot, and you will hear Orca start up. From there you can go through the setup wizard with Orca, and after it is complete Orca should always start automatically. From there, you can open a terminal with Ctrl+Alt+t, run "sudo apt install brltty" to get brltty installed, and connect a Braille display over USB. You can also use espeakup instead of Orca, which is a better screen reader for the terminal and brltty is also better on a plain tty rather than under X. To do that, run "sudo apt install espeakup", switch to tty1 with Ctrl+Alt+F1, and you should have speech. I did notice some accessibility issues with the default desktop environment, and sometimes espeakup would randomly stop speaking for me, but I did not investigate those issues since I just used Raspberry Pi OS to install and switch to Arch Linux.
@Doll Eye
Six months ago I tested asahi linux fedora and gnome latest versions at the time and I shared my experience in this thread.
https://www.applevis.com/forum/assistive-technology/thanks-europe-asahi-linux-wayland-gnome-about-become-usable-blind
It's a bit misleading in the title, stf has nothing to do with asahi linux but rather that the timing of orca and linux accessibility stack improving on linux coincided with that of asahi linux.
Wow... @emassey
I've been ignoring those Raspberries for years. The OS doesn't sound too bad out of the box, and the 500+ is too tempting... Even for just an on-the-side or backup computer.
Raspberry Pi Accessibility
I'm totally blind and do plenty of development on Raspberry Pis, historically the more powerful single board computer models, but am pivoting to their microcontrollers now since I love challenging myself with seemingly impossible optimization goals on very limited hardware. When the Pi 5 came out, I was even one of the first people on the official forums to write sample code for it on bare-metal, since the hardware is not documented, and even that doesn't stop me, so accessibility is definitely not an issue.
As for just running Linux on a Raspberry Pi, all single-board computer models contain a Micro-SD card drive and USB ports that you can use to run any of the many distributions that provide official support for the platform, and some models like the Compute Module also ship with internal storage that can be filled via USB. Beyond that it's just a matter of connecting them to peripherals and they work as pretty normal Linux machines, except quite slowly compared to a modern desktop computer especially a Mac, which can be annoying if you try encoding video or compiling code on them but for most tasks that's not really an issue.
As for the usefulness of Braille to read punctuation and spacing, I cannot disagree more. Punctuation is quite irrelevant in the grand scheme of things since in the overwhelming majority of cases the code will simply fail to parse if the punctuation is wrong, and for spaces one can simply configure the screen-reader to convey the number of whitespace characters through the pitch of a short tone, so those aren't real issues. What is an issue, and is also the reason why I strongly doubt that Braille can be of any use for coding when hearing is an option, is that with Braille one has to stop whatever they're doing to get feedback, whereas listening to the words and characters as they are typed feels a lot more natural and closer to a sighted experience.
Braille
@JoĆ£o Santos Iāve published Beaver with deaf-blind users in mind. Itās also worth keeping in mind that hearing loss can always occur later in life. From that perspective, overloading the audio channel with many tasks, instead of distributing information across a second sense, may not be the best long-term strategy.
Your statement that you āstrongly doubt that Braille can be of any use for coding when hearing is an optionā also likely doesnāt align with the experience of many blind developers. Just my 5 cents as a sighted developer.
Braille efficiency
I don't deny that Braille can be used to code, and in fact you can even use smoke signals or pigeons if that rocks your boat, and shortly after I went blind I even dictated code to one of my cousins to help her solve a problem because I was yet to figure out an adapted workflow, but all that is highly inefficient, not as far as smoke signals of course, but also not as efficient as immediately getting audio feedback from the screen-reader as you type especially at higher speech rates.
I can't even imagine reviewing someone else's code with Braille in a useful amount of time, not to mention the mental drag involved in the process distracting you from the code itself which is what really matters. When I returned to coding I couldn't believe how much mental resources I was spending to code with a screen-reader, and I strongly believe that I would be much farther in terms of knowledge and experience if I hadn't lost my sight, so I can't even imagine the loss of productivity and reasoning ability if I had to put up with Braille for coding. We're already at a huge disadvantage as it is, it doesn't make sense to make the situation even worse with suboptimal methods.
Re: Braille Efficiency
I cannot see why reviewing code in Braille would be particularly slow. Yes, you can have your screen reader indicate indentation with speech or beeps, and make it read all punctuation, but it seems like that would be more "mental drag" than just reading the line in Braille. Reading a line of code in Braille feels more direct to me, like I am directly perceiving the spacing, punctuation, and spelling rather than interpreting the audio output. Often when I use speech to code I review the line word by word and go character by character on some words to make sure I got everything exactly right and I'm not missing something that sounded similar but is in fact a little different, where with Braille I notice those things instantly. There is the disadvantage of only a single line so you have to pan or navigate a lot to read larger sections of code, but I have the Monarch and I wrote an app for it that brltty can connect to, so I can start Emacs and have ten lines of the buffer displayed in Braille and pan between pages of the text on screen, which makes reading and navigating code significantly faster than speech I would say.
Use terminals extensively
I use Linux (including the terminal) extensively. I don't think graphical user interfaces have ever achieved the level of accessibility and efficiency that the text-based terminal provides.
There are subtle differences between Linux commands and the BSD-derived versions on macOS, so be sure to look up documentation if you use both environments.
Although BRLTTY used to run under macOS and perhaps still does, I've only use it under Linux, so I can't comment on its status for the Mac.
Getting it wrong
You don't really need to read all punctuation to review code, since in most cases the code won't even parse without the right punctuation. Misspelling is mostly irrelevant either if you are reviewing code written in any language worth using to develop a final product as that will very likely fail a semantic compilation step, so you'd have to be quite creative to cause problems even intentionally with that, not to mention that we are far less likely to make that kind of mistake than the sighted since small differences in the way deterministic speech synthesizers pronounce things make misspells quite evident with a screen-reader. The sighted make spelling mistakes and also let them through review a lot more often than I do, since they are more prone to the pitfall of getting tricked by glyphs that look roughly the same, like lowercase and uppercase F, lowercase L and uppercase I, uppercase O and 0, and even lowercase C and lower case E, with monospaced font usability being an actual subject of research. I do catch a lot of sighted misspells in comments and string literals, for example, and some languages, Swift included, their designers decided that for some reason people should be free to be creative with non-ASCII characters in binding identifiers and operator symbols, so you also have to configure the Continuous Integration pipelines to reject that crap as it can actually be used for nefarious purposes like hide perfectly working malware from review. Finally I strongly doubt that you can read Braille at over 400 words per minute, but even if you can, that's definitely not a common skill, so that's not a very useful suggestion in the general sense, and obviously having to switch between typing on the keyboard and reading the Braille output when you can just get feedback right away through a completely different passive sense does slow you down no matter how you frame the problem.
In 11 years of blindness, I have face a grand total of zero problems arising from misspells reviewing code and only the following example of a problem arising from a rare case of punctuation misuse that still resulted in valid C code:
In the above example, which reproduces an issue that I came across while helping someone debug code on reddit, the problem was only evident to me after actually trying the code and noticing that it was indeed misbehaving, because in C it's perfectly fine to omit the body of a loop, and since semicolons are used to mark the end of statements and I never have the speech synthesizer configured to read all the punctuation, that empty for loop with an indented statement right below got through my first review, but that's the only real problem that I had relating to the misuse of compilation, and compilers often do warn about these things which should prevent code from actually getting green lit for review in a professional environment.
I actually just tested something like the above example on
clang:And it produced a warning:
Which should be promoted to an error as follows in professional environments so that it doesn't actually get accepted for review:
But regardless, that's the only punctuation problem that I ever had reviewing code without any sight, and that still didn't get through after a more careful inspection, I am only mentioning it because it could get through less rigorous developers.
Speech and Braille
Okay, for reading large portions of code, speech is probably faster, and I suppose for that use case of reviewing code speech is probably faster. But when I am writing code, I think Braille makes me more efficient. For example, if I type a left bracket instead of a left brace, or a right parenthesis instead of a left parenthesis, yes the compiler will give me an error, but it is faster for me to catch that on my Braille display right after typing the line than for me to review the compiler output, review the line with the error, notice the wrong symbol, find the line number, and navigate to that line in my editor. Also, when I am working on code indented four or five levels, which can easily happen if you have a match statement (two levels), inside a loop, inside a function, inside a trait impl, or if you have nested map invocations, it is very easy for me to go line by line on my Braille display and check that everything is lined up correctly, where with speech I might have to count spaces manually on every line, or at the very least hear 10 spaces, eight spaces, etc and match them up. That is not too bad but still I prefer just keeping my finger on the same Braille cell and instantly knowing the indentation. And this is something the compiler will not warn me about (unless I'm doing Python), but it is a detail that it is good to get right. Also, I often type code on the Perkins keyboard on my Braille display rather than the QWERTY keyboard above it, which makes going between typing and reading much faster. Typing on a QWERTY keyboard might be faster, but often I do not type large amounts of text anyway since I am constantly thinking about how to do the next part or rethinking if what I am currently writing is the best way or will work well. When I do type a lot of text at once, I always go back over it and review it in detail to make sure I didn't miss anything small, either with Braille or with speech and often reviewing certain things word by word or character by character. But if I am reading someone else's project trying to find something or checking some detail in a different part of my own code, I will use speech for that and go through it very fast, at 900 words per minute with eSpeak. Yes I could never go that fast in Braille, but I use Braille when I am not reading that fast anyway because I am very focused on detail.
Still missing the point
When you are typing, at least on macOS, the speech synthesizer does spell out every symbol and word that you input if you have it configured to do that, and you can even configure the way they are conveyed with your own made-up words or expressions. Many people actually do it, by replacing long character names like left parenthesis and right parenthesis with LParen and RParen, left bracket and right bracket with LBrack and RBrack, left brace and right brace with LBrace and RBrace, and even less than and greater than with LAngle and RAngle. Common symbol sequences can also be turned into more familiar representations, like number exclamation being turned into their famous HashBang or just SheBang monickers, or the colon colon less than greater than being appropriately applied the Turbofish monicker as it's known within the Rust community.
As for indentation, the pitch of the short tones that I mentioned earlier make checking for code alignments a lot more intuitive than using touch for the same purpose. If you're writing code with 5 levels of indentation then the problem is how you are structuring that code, because in Rust, which I can infer to be the example that you are giving since that's the only language where trait is an actual technical term (C++ has traits but they are only standard library types), modules are implicitly declared for every file so trait implementations are almost always declared at top level, meaning only two levels of indentation inside functions. I was convinced that the Rust compiler or at least Clippy did warn about inconsistent indentation for some reason but am apparently wrong as I just tested both on stable and nightly, however you can always run
rustfmtorcargo fmtmanually or automatically before reviewing any code, which should get rid of all inconsistent indentation except within declarative macro calls and declarations, the C family also has its own standard formatting tool conveniently calledindent, and regardless indentation is an editor problem that can be easily solved by the same regular expressions that offer syntax highlighting to the sighted so pretty much every code editor provides the ability to fix it one way or another, and in the case of incorrect indentation that I used as an example earlier, I had to go out of my way and actively fight TextMate to get it to produce that text.Typing Feedback
Everyone's tolerance will be different, but although it's possible for me to receive speech output, when using Braille I choose not to. So long as you have reasonable spacial memory and a decent accuracy, you will eventually learn to type or Braille confidently. I too use my Braille display's keyboard, often with the screen locked and the QWERTY keyboard unused, to iterate some code I'm working on. I tend to be very particular about getting things right, in part because, good as compilers are, they can often lead you down the proverbial garden path when some error is caused by completely unrelated code, so I do like to ensure I haven't missed anything completely obvious. Not to mention, if I did just listen to the code, I'd probably miss something even if listening with maximum punctuation.
Different strokes for different folks, I guess. But I'd really rather have an 80-cell Braille display. If I could afford it, I would.
Contradictions
So you're careful to get things right but choose to opt-out of safety by disabling typing feedback because you have allegedly good spatial awareness and accuracy? I thought that Braille was supposed to make it easier and less error prone, not create more dependency on skill and prowess, because otherwise you are actually confirming my arguments about the unnecessary mental drag resulting from using Braille for coding...
I'm also not even sure why you keep going on about listening all the punctuation while reading code when I have already mentioned more than once that it's not a requirement, explained exactly why, and even stated that I don't do it myself and that have only come across one potential situation in which it could have been a problem since going blind. I could understand confusing listening to all the punctuation as typing feedback and listening to all the punctuation while reading code, but as someone used to screen-readers I assume that you are well aware of the difference.
Question for Coders
When you are writing code or even commands on the command-line, are you thinking in that language directly and remembering all the code variables and syntax, or are you looking up pieces of code and filling in your specific details, file names and such?
Re: Question for Coders
I do remember all the syntax, which is usually the easy part of programming. I do write code in pretty much all the mainstream languages but can get rusty if I don't touch a specific language very often or for long periods of time, which are the cases of Perl, Python, Lua, and Objective-C for me, however it doesn't take very long for me to get back in shape once I return to a specific language. New languages tend to be a bit harder to learn with most of the challenge coming from learning new paradigms, which becomes increasingly rare as you progress in seniority but happens sometimes when there are breakthroughs as in the case of Rust, and the remaining challenge is just learning the conventions used in new languages in order to write code that feels both ergonomic and idiomatic, which many developers simply refuse to do for some reason. As for variables and all kinds of identifiers, they do exist to serve as mnemonics to make the code more accessible to humans, so if the name of a variable doesn't intuitively convey its purpose to you, that means that the developer who wrote the code failed as an engineer.
Good engineering is all about being able to solve complex problems by breaking solutions into layers of abstraction that are individually easy to reason about and whose overall structure is also easy to understand, but without sacrificing resource usage in the process since the computers on which our solutions will run are not ours so user experience must always take precedence over developer experience. Good code leaves everyone feeling like they fully understand how it works while being extremely performant and sophisticated, so I feel proud when a novice engineer tells me that they understand my code. While a good engineer must have the ability to navigate complexity and chaos, failure to produce elegant code means that they don't truly understand the problems that they are tackling, because only feeling comfortable to break your solutions down to the point that even a curious 5 year old kid would understand your train of thought demonstrates that you have truly become an expert in those specific knowledge domains, and the difference between proficiency and expertise is the existence of useful intuition in the latter case.
To add to what JoĆ£o Santos said
Language syntax is indeed the easiest part and one where LLMs will truly be very helpful. But so far auto complete on steroid has not beaten a good engineer (yet) so I have plenty of job opportunity left once I graduate š
Re: Autocomplete
One place I have seen autocomplete be truly beneficial, is in Cisco's IOS environment. Not to be confused with Apple's iOS. ((Note the spelling).
Interesting
I suppose it would come from constant use. I can often recognize a line of code, and maybe even tell if something sounds a little off about it, but more often than not, I can't just regurgitate commands and such as if I were trying to write a post.
@Brian
YESS and aliases / shorthands too. 101% agreeing with you on this.
I'm skeptical. Going to poke it from within a VM
What is this offering that I can't get from installing Debian or Arch or Gentoo with Speakup andBRLTTY enabled?
UPDATE: After skimming the linked repo, it looks like it's a Debian package with a collection of everyday productivity apps (think a web browser and email client).
It's got an OpenAI CLI client, so that's nice I guess.
It doesn't immediately look like malware. I'm gonna spin up a Debian VM and see what I can do with this thing. I'll report back with my findings
Configurations
@Brass: If you need help with configuring mail, ai, mastodon, just drop a line. For the beaver-ai client you'll need to get an API key from OpenAI.
Just a collection of FOSS apps. Unimpressed
This seems to be just a collection of other apps, so I'm still not sure what benefit this brings to blind users.
A novice user will still have to learn the basics of the terminal. An advanced user will just download the apps on their own from the package manager. All users will still need to be running Speakup and brltty. The accessibility is coming from those two services, not from Beaver.
This installation is janky. Users must either be familiar with Docker or they must be willing to install several .deb packages. I wrote a bash script to install all of them. If you expect a user to install all of these apps, the least you could do is include an installation script as part of the release. If a user is familiar with Docker on the command line, chances are they have enough skills to make Beaver redundant.
The usage instructions are bad. The help message does not follow the format of a unix-style man page, and there is no man page proper available for Beaver either. The readme is not any more helpful and even lists
beaver onboard, a command that does not appear to exist in release 0.1.0.This app collection strikes me as something built by someone who does not understand the needs of the blind community and does not fully grasp that the skill set needed to use Beaver is also the skill set that makes Beaver redundant. A lot of the language in the readme is also reminiscent of something that was vibe-coded. The /very short commit history does that suspicion no favors either.
In conclusion, These are just a bunch of loose apps that someone has packaged up. They do not improve the accessibility of the Linux terminal environment for blind users in any tangible way. Install Debian or other distribution of your choice and learn how to install and use these tools yourself. You will get much, much, much, much further in the world of GNU and Linux if you do.
Answer to the comment of @Brass
I am inviting blind programmers to use Linux and to work primarily from the terminal rather than from a GUI. I do this because I have read many posts by blind programmers who struggle with large integrated development environments such as Visual Studio or Xcode.
I fully agree that installing Linux and those tools directly is perfectly fine, and there is no necessity to use Beaver. Beaver is simply something I use to demonstrate what terminal-based applications are capable of, and to offer a small set of tools for everyday use. As stated in the description, the package is still in an early version.
The post is not about the Beaver package itself; it is about āTerminal-Based Linux as a Practical Platform for Blind Programmers,ā as the title clearly states. Since @Brass appears to have missed that point, I am not taking the comment too seriously.
Biased research
Reading this makes me wonder whether you actually consulted with professional programmers, because struggling people are quite easy to find. I struggled in the past myself after going blind, and had nobody to look up to and follow as an example, so I head to come up with my own way of doing things, and today I find myself sailing uncharted waters with lots of confidence, because life has shown me that not only was my professional career far from dead, but also that I can still be a valuable asset in highly competitive markets without requiring pretty much any kind of accommodation beyond what Apple systems already offer out of the box.
Xcode is almost completely accessible, with the least accessible parts either being totally irrelevant these days or the accessibility problems easy to work around. If you browse the Developers Room on the AudioGames Forum you will find plenty of developers on Windows, some of them with actual software engineering careers, who swear by Visual Studio Code. Graphical user interfaces provide semantic information when they are accessible, meaning that we don't have to try guessing exactly what kind of action we're going to perform, and can take advantage of screen-reader controls to make navigation more efficient.
While I understand that a pure text Interface might sound appealing to a blind audience, the fact is that, short of command-line interfaces, text user interfaces can actually be quite counter-productive. Therefore, at least to me, and as I have already demonstrated above, the only thing text interfaces may actually be good at is providing control.
Bias, Preference, and Accessibility in Developer Tooling
If I am biased, it is only in the sense that I personally prefer the terminal, vi, tmux, commandline git, build, deployment and so on. That does not invalidate the experiences of blind programmers who struggle with IDEs.
Different experiences
As I said on the first comment to this thread, I have a strong background in Linux in particular, most of which during my sighted days, so I am perfectly aware of what you're talking about since, until Compiz came out in 2006, my desktop was just Blackbox / Fluxbox providing window management to XFree86 / Xorg; Netscape Navigator / Mail for web browsing, E-mail, and newsgroups; and a bunch of Xterm windows with shells for everything else like
vimfor editing all kinds of text; CVS (yes I used that shit) / Subversion / Git for version tracking;mpg123/mpg321/playmidifor playing music andstreamripperfor ripping Digital Imported (known as di.fm these days), BitchX / irssi for chatting, and lots of other stuff that I forget now, so yes, I understand where you are coming from, but the blind experience is totally different, there's absolutely no parallel that you can draw from a sighted perspective. That is why people should do proper research when they think they can solve our problems, and the best people to gather information from are actually the ones who find ways to thrive, not the ones who give up on the first sign of difficulty, because the former may actually have something to teach especially about what has been tried, what really works, and what might be just useless gimmicks.Objective Judgement Problem
When it comes to command line ... vs. IDEs then even most sighted developers think, that programming with vim is dumb. On the other hand there are some vi wizards, who can demonstrate insane speed. Vi is hard to master or even start with, so the situation is actually inverse. It has a much higher entry barrier, than IDEs. But how to compare those paradigms unbiased? It always begins and ends with personal preference, experience, and individual efficiency and time tells.
Re: VIM
Back in like 2015 or 2016, I actually thought VIM was pretty cool on macOS. I was first learning Python, I forget what version, three point X of course, but anyways vim was the one and only editor (at that time) that I was aware of, that actually marked indentation in a way that a screen reader could pick it up. I can't remember if it was tab or space, but every indentation would be replaced with a carot (^) symbol. Made for some much easier code writing and code editing for Python.
Just my 2 cents...
addressing the whole post
Since the post is apparently not about Beaver, even though everything in the post leads up to the link to the Beaver repository, I'll address the post.
I love the CLI. I use it nearly every day on my Gentoo system over SSH. I still use VScode on Windows and Firefox forks on GNOME. The CLI is a useful tool, and it is not objectively better than a well-built GUI environment. The problem of usability and testing doesn't go away because you drop to a text environment. Positional and color encoding is still possible, not to mention the TUIs that other users have mentioned here. I use screen regularly and I've had to memorize some commands because the visual hints at the bottom of the SSH window simply aren't read by a screen reader.
Now to address Beaver since it is part of the original post, if this is just a showcase, then you need to make that absolutely explicit in your post. Right now it looks an awful lot like you're proposing Beaver as /the/ terminal solution for the blind. This is misleading.
If you really want to get blind users started on using a CLI, write up a guide linking to using package managers and basic GNU packages. Show them how to get WSL started in Windows or how to open up a terminal window from GNOME on a Debian machine instead of posting your showcase tool.
Linux System Administration
One common use of the terminal is system administration, which usually involves accessing servers via SSH, scripting, editing and server side programming. These roles are often well paid, making this another good reason to become comfortable working in the terminal.