Blind coding

I want to talk about what it is like coding mostly blind. This is especially true for me as my eyesight continues to worsen and my chances for any corrective surgery continue to recede and anyway proved now impossibly costly. Of course what constitutes blind, visually impaired, etc, is a very broad range. Being unable to distinguish n from m may be a very minor issue, But I think no longer being able to safely cross a street because I cannot see approaching cars is closer to blind.

First, though I want to write about this separately, forget the very idea anyone will want you to work for them. Even modestly impaired, if they ever figure it out during an interview they will treat you horribly, too. If they find out later, they are quick to fire you, no matter how effective you are. In the US hatred of the disabled has only grown recently. Asking for accommodation is at present like saying “I don’t want to work here”, and they are very aware federal labor laws are no longer being effectively enforced. The tech companies seem some of the worst, too.

I find I work most effectively by visualizing code in my mind. This is easy with languages that correctly represent themselves. I can do it with C/C++ and especially go, as imperative languages, and Haskell as a declarative functional language. That is why I keep emphasizing syntax and correct representation is so very important, whether writing, reading other code, or trying to debug logical errors.

The biggest issue for me is typing. Having a clear idea of what the code is in my mind, I have to now transfer that to an editor with very marginal eyesight where everything I see, even with monochrome, is still now blurry. Touch-typing helps, but when you make even simple mistakes, they are so hard to see. Editors that do live checking only create interruptions and popups that may also be blurry and distract that work flow. When later correcting code, VSC can actually be more helpful to me, but to get the initial bulk of it down, I have to go from mind to editor with as little interference as possible.

What I found works for me is actually having AI proof-read and correct my typos for me, or even explain the weird compiler errors I cannot properly see. And with C++, especially, you can get some massive and weird errors. Sometimes it wants to refactor what I write or wants to “suggest changes” that often are actually wrong, but I have found how to prompt it to just give me corrected but otherwise unaltered text. Working this way, between visualizations and proofing, I now code faster and more reliably than I did with more normal sight.

This desire for simple monochrome editors is why I often choose vim. But I will say Visual Studio Code can also be a godsend for visual impairment once you disable some of the more distracting features. Sometimes having smart typeahead is even useful, too. It knows how to scale its Ui, and it has a high contrast mode that actually works reasonably well for me. It even draws those border lines modern Ui designers seem to have decided to remove because shades of impossible to distinguish greys are all the rage.

Another great tool that has worked for me is LibreOffice. I am able to effectively draw design diagrams in high contrast mode. However, since it makes everything black and white, its not always clear how what you are drawing will actually look until you are done and export it to something else, like a Png. I also wish in high contrast mode it did the arrows for lines too; it somehow missed fixing these in high contrast mode, and I very much notice that when doing a design document.

In respect to proper ui design, a platform that works really well is an old X11 desktop. Back then they did proper borders and black really was flat black, not just dark gray making text even more blurry. Splashes of graphic images like X11 used to do are okay for me, but websites that have images up front and in your face are actually blinding to me, and I am unable to read any text around that now. The X11 xpm format is also text! I can do a desktop ui like that again.

Windows offers an okay but inconsistent accessibility experience. There are different parts that seem written with different toolkits, some of which know and use themes, high contrast settings, and font size selections, and some (like the explorer file manager) that do not. But when and were accessibility settings are supported, those applications work very well. This is why I switched from nsis to innosetup for my mingw32 installer builds.

Some claim MacOS is the “gold standard” for computer accessibility. I do not know because when your blind the last thing you can afford is anything expensive to begin with, and least of all, something that must be re-purchased every five years.

While older X11 desktops, and even gnome 2, were great for accessibility, and 25 years ago blind users at the American Foundation for the Blind were able to work on computers for the very first time using gnome 2, modern Linux / Wayland desktops absolutely suck at it. A few years ago, when dealing with the fact that Orca no longer worked on Wayland and that gnome’s “accessibility” mode with it’s theme breaking adwaita coloring library, when high contrast is enabled, replaced dark themes with a dark text on pure white that, to me, effectively was just a giant blurry grey rectangle,

I was told flat out by Gnome developers that accessibility was a use case “we don’t care about”. This of course is how accessibility became broken in Ubuntu 24.04. Unlike Gnome, KDE does care about accessibility, but they have special challenges. The Qt QML core never was designed properly for applications that could offer accessibility modes unless you re-write an entire alternate QML Ui from scratch for each use case. Instead, KDE has been working accessibility into Kirigami, which sits above QML, and in other places like that. This also requires accessibility to be implemented in each application. But at least they really do care!