The most immediate suggestions that come to mind are:
1. Learn to use a screen reader. You don't need an expensive one. NVDA on Windows, Voice Over on the Mac and Orca on Linux are the way to go. NVDA is probably the least quirky and easiest to find resources for. I'd recommend against Orca, while it can be used, we all know how tricky Linux on the desktop can get, and throwing a screen reader into the mix doesn't help.
2. Forget about the mouse. Screen reader users use the keyboard exclusively. Try disabling the screen too, many sighted users who practice with a screen reader end up relying on what they can see, which makes things more difficult.
3. Accept that inaccessibility is a fact of life, and it has to be worked around. Not all tools are accessible, and some are more accessible than others. If you're looking for an accessible IDE, Vs Code is great and constantly improving. Emacspeak exists, but I don't actually know anyone who uses it, and I know quite a few blind people in tech. Some things that you're now doing through a GUI are best done via the command line, Git is a good example. Programming tools usually aren't the problem, it's everything else that causes issues. Slack and Zoom work great, for example, but many smaller collaboration tools don't.
4. Not all areas of programming are equally accessible. I can't imagine a blind dev working exclusively on the front end, where there's a lot of CSS involved, and where you have to look at Figma designs and debug issues solely based on screenshots. Backend stuff is much more accessible, same with lower-level systems programming. Dev Ops is very much a mixed bag.
I'm happy to answer any further questions either here or via email, my HN username at gmail dot com.
"Ask HN: I'm a software engineer going blind, how should I prepare?" https://news.ycombinator.com/item?id=22918980
I have two very close friends who are Blind, one is an SRE and the other is a data scientist, both use different types of assistive technology but have found that Linux and MacOS tend to work better than Windows, partly due to the availability and usefulness of the command line which is a better UI for a Blind user than a GUI. There are now fantastic screen readers which are free and/or open source available on these OSes.
Those are a precious few months, figuring out software can wait, maybe help them enjoy their remaining vision.
If it was me I'd want to see as much of the sights of the world as I could while I am still physically able. Not everyone will have this mind set, but they may be regretful later if they don't.
It's not big and it doesn't see much traffic but you or your friend are welcome to join.
If you have the ability via your employer or individually to purchase LTD, you should really do so.
Apple in particular is the only major technology company left that truly prioritizes the end user, and that goes for disabled users as well. So moving entirely to the Apple ecosystem will be a win for accessibility -- iPhones are perfectly usable by blind users.
Another one is Ecasound, a command line oriented multitrack digital audio workstation [2] and its front-end Nama [3] that even supports so-called non-destructive editing. A patient, determined person really can accomplish a lot solely on the command line; also, compare Ecasound's resource usage with with what it takes to run Pro Tools or something similar.
Curiously, the initial version of both Ecasound and Edbrowse was written in Perl -- I wonder if that language has had any particular appeal to blind users, e.g. because of its text processing abilities or regex engine?
Considering the maturity of the aforementioned projects, their mailing lists may give great insights as to how to do your computing as a blind person. I would also point out an essay on the user experience by Edbrowse's author Karl Dahlke [4].
Dahlke's homepage has other interesting links and applications as well, including speech software and an essay on subconscious from a blind person's experience. Mind-opening writings and works, even for a regular user like me.
I'm wishing inner peace and balance for the adaption period to the OP's friend. Best of luck, man.
2: http://nosignal.fi/ecasound/
All the best for your friend's health!
Kudos to all of you who did that, and do that emotional labor for everyone without even so much as calling it out, I recognize it and while I also do it as well so people understand a different point of view I know how tiring it can get. And sincerely thank you for that point of view and the resources provided in this post thread. I know that your challenges in computer accessibility are ones that I had not really considered much Beyond just you know knowing that blind people use computers and there were probably blind devs obviously, but not having the fortune to work with any as of yet it's not been something anywhere even close to the Forefront of the accessibility challenges that I've considered. Which is quite silly considering it's as plain as the nose on my face, and yes pun intended :) . And using that emoji just made me wonder how well do screen readers handle emojis? I can only imagine what ascii art sounds like to a screen reader. Thinking about it further I realized that the only blind person I have ever personally known that I'm aware of that used a computer on a regular basis and played games, I used to play with in a MUD back in the BBS days of the early 90s.
Anyway to those of you who have challenges or lack of sight thank you for your Insight and perspective into those challenges you face every day and deal with every day. And show us that the human body and mind is incredibly resilient and adaptable.
If your friend wants to go the Linux route, I would suggest to pick a distribution with a blind community and if possible blind developers. Arch Linux would probably work, and I am pretty sure Debian too since a recent Debian Project Leader (Sam Hartman) is blind. There is also a Slackware derivative called Slint.
Regarding tools I have seen blind people use different things. Some use the CLI exclusively with a braille terminal and/or a tool like Speakup, others use GUIs like Orca.
There is a mailing list dedicated to blind Linux users: https://listman.redhat.com/archives/blinux-list/
Note: I'm not suggesting your friend picks Linux, it looks like accessibility on Windows is better, but I know if I was in their situation I would probably still pick Linux because I already have experience with it and using an OS without a GUI.
Best of luck to you and your friend!
Nothing serious but still scary.
All the best to your friend, may they have the power and support to go through this change.
Put a blindfold on, and see what works and doesn't work. Take the blindfold off, and try to fix what doesn't work while you can. Rinse, repeat.
I know that a11y is a requirement is lots of places, e.g. education -- you cannot sell a software with UI to a school if its not accessible. These companies are constantly on a lookout for people who know a11y tools well, and are often in a dire need for people who use these first hand.
Firstly, my impression is that people tend to overestimate the practical challenges associated with vision loss and to underestimate the psychological side of it. These things are of course linked – the more quickly someone accepts the fact of their vision loss, the more open they become to using various forms of access technology. That said, coming to terms with vision loss is not something you can rush. It took me a long time.
Secondly, I don’t think it is necessary to try and learn everything before you actually need it. By all means, encourage your friend to install NVDA on a Windows computer and mess around with it when he feels like it, but for the most part I’d say use your eyesight while you have it. I don’t think he needs to worry about getting stuck if he doesn’t learn everything ahead of time. He might also be more motivated to learn new tools once he really needs them.
Two critical things to learn will be to touch-type, if he can’t already, and to use a screen reader like NVDA or JAWS. These are underlying skills that will make everything else easier. By learning a screen reader I mean learning its basic usage, but also learning a whole set of new screen-reader-specific short-cut keys. People who don’t use screen readers often make the mistake as thinking of it mainly as a text-to-speech engine, while in fact the essence of a screen reader is the multiplicity of ways it allows you to interact with the computer in non-linear ways. To be an effective blind/low vision programmer, it helps a lot to be a super user of whatever screen reader you use. The related thing that should happen naturally is that he will set the TTS voice to speak faster and faster – which brings us to another point. One of the most popular TTS engines is Eloquence, which in fact is one of the least natural-sounding TTS voices around – but that has the advantages of working very well when speeded up and having very high latency (at least that is my perception). In time he will find that things like voice latency really matters as your brain gets used to this new way of working. In any case, Eloquence may not sound like a first choice when you first hear it, but for the above reasons it is my recommended TTS for new users.
When it comes to actual programming, I have found that most things can be done, although one often needs work-arounds, and there almost always is a workaround. For example, for data analysis I often use the R package RMarkdown, which makes it easy to e.g. render data tables as screen reader-friendly HTML (while R Studio has improved somewhat, it still isn’t fully accessible). I mainly use WSL and either VS Code or Notepad, depending on what I want to do – unfortunately many IDEs are only partially accessible – on the whole I have had to learn to do more from the terminal than before, including debugging. In any case, I get along just fine working on c++ projects and I’ve found few obstacles when programming in Python, Julia or R (although Jupyter notebooks are a problem). Incidentally, for a long time I avoided Python because I thought the indentation would be a problem given my lack of eyesight – but when I finally tried it I found that having the screen reader announce the indentation level actually works much better than I thought it would and these days I am perfectly comfortable in Python. As with many things, simply trying it, rather than being limited by my preconceptions about what is possible, was the key.
Finally, there are online communities of blind programmers who will have already figured out many of the work-arounds your friend might need and who are generally very willing to help. An R-specific group has helped me a lot over the years – but there are many others.
Good luck.