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.
We have a heavy documentation culture at Stripe so as a developer these tools matter a lot.
Google Docs works, there are two accessibility modes, none of which is enabled by default. The old, standard mode hides all content from screen readers and uses a built-in micro screen-reader that outputs whatever is needed to a live region, which your screen reader then reads. The newer one, called braille mode, actually shows you the content, only relying on ARIA when absolutely necessary. Both have their pros and cons, but I'd recommend using Braille Mode for most things, unless you run into use cases that the legacy mode handles better.
I've heard people say that some really advanced docs features have accessibility issues, but I haven't used it that extensively to confirm that.
As always, Etherpad, the open source / non-proprietary / privacy-friendly alternative boasts about being accessible but has so many a11y bugs that it's basically unusable. As always, markdown over git works better than any web-based solution ever could.
Accessibility at Google suffers in the same way as most UX-related things suffer at Google. Namely, the fact that everything is constantly reinvented from scratch, rather than there being one unified way to do it. As a screen reader user, I can say that in some Google products, there can be instances of what, on the surface, should be exactly the same component, but was apparently developed in multiple different ways. This leads to the constant need to work out how accessible each instance is (and e.g. what keyboard support it has), even though I dealt with the same UI pattern minutes ago.
Updates definitely affect your workflow, you need to be careful about what updates you install. This is less of a problem with coding-related tools, but definitely a nightmare when mobile apps are concerned, for example. Web apps are even worse, as you can't avoid updates that completely break accessibility. I've heard stories of people getting in big trouble because a web app that was critical for their job suddenly had a UI overhaul and stopped being accessible. OS updates can cause trouble, in fact, Windows constantly breaking things with their forced updates was one of the major reasons why I switched to Mac OS. It wasn't even accessibility-related, most of it was basic stuff like sound.
iOS and Mac OS definitely win in terms of what's built-in, the screen reader they come with is more than enough.
JAWS, a paid screen reader for Windows, is perfect for enterprise environments, as it works well with Microsoft Office and Common productivity applications and lets IT administrators enforce security policies. At also has a vibrant market for scripts, both free and paid. Those scripts add accessibility to third-party apps. Companies can even hire script developers to implement accessibility for the internal apps employees need, which is often important in big corp / government, and it is in those environments where JAWS thrives.
NVDA, the free Windows screen reader, is more suited to software development work than JAWS in my opinion. It's written in Python, which makes it much more flexible, but also much harder to learn script development. There's a big collection of addons and plugins of all kinds, from speech synthesizers and braille display drivers to full on remote access suites (which no enterprise security policy can block), but all of those addons need to be released as GPL, which discourages any development on addons for internal and professional applications. In many countries, NVDA has replaced JAWS entirely, even in the enterprise.
Narrator, the built-in Windows screen reader, is getting better with each year, but it still isn't on par with other solutions that we have. It's great for installing another screen reader or figuring out why your existing one doesn't work, but that's about it.
Linux is a shitshow, free software zealots will claim it's perfectly accessible, while many problems still remain. It can be used, but it's probably the least accessible out of the big three, at least when the GUI is concerned.
Android works, people use it, but iOS works much better. IPhones are much more popular in the blind community, even in countries where they're extremely expensive, even considering the fact that blind people are often unemployed or have low-wage jobs. Android has quite a few rough edges and thinks might not work the same way on different phones. It's been getting better over the years, but even something as simple as accessibility on first setup isn't guaranteed, something that Apple has basically figured out more than 10 years ago. It's much more common for an Android phone or a Windows PC to fail in a way that requires sighted assistance than it is for a device running iOS or Mac OS.
My experience with corporate IT has been that they're not great at, or under resourced for, any outside-the-box situation.
But since accessibility software is a legal requirement, at least in the US, I'm curious if that breaks the tendency to inaction.
In the US, this seems to be much more of a concern, so JAWS is often a requirement in big corp / government.
There’s no denying blind persons face unique challenges, but I’ve been seriously impressed with the fortitude and adaptability I’ve seen them display.
As an aside I wish more developers would think about accessibility. It helps everyone. I highly recommend participating in dining in the dark or a similar program to learn real sympathy for the challenges blind persons face and to see how capable they are of overcoming them.
I’m a sighted person and I’m not going to pretend I know what the right technology for any particular blind person is, but computer braille really is fascinating.
Edit: I’m not a hardware guy, but it feels like an 80x24 or larger computer braille display is well within the capabilities of today’s hardware hackers. Imagine a reverse mechanical keyswitch with 8 dots that can be put on a PCB of arbitrary size in whatever configuration to understand what I have in mind. There’s probably not much money to be made, but someone with a passion and existing financial success could really make a difference.
I'm particularly bad at piecing together a larger context from smaller pieces, so maybe it's easier for others, especially if they are forced to?
Navigation with a screen reader isn't just next item / previous item, though. There are hotkeys to jump between headings, links and so on. That's why good markup is so important for accessibility.
It seems that it should be possible to make cheap full screen braille displays, I suppose it's just that the volumes are not big enough to drive down prices.
Anyone who spends a couple hours on researching the problem thinks that the price could be improved, maybe by half, but that the problem isn't as easy as it seems.
Anyone who tries building one eventually arrives at the conclusion that making it cheaper requires a bunch of tradeoffs which they're not willing to make.
As far as I know, the central problem off Braille Display engineering isn't making the dots, but putting them so close to each other. If the gap between dots would be half an inch, let's say, a braille display would probably be a hundred-dollar affair. It would be completely unusable for any kind of reading, though.
Orbit Research managed to find a way to make Braille displays somewhat cheaper, which is now incorporated into the Orbit Reader 20 and 40, but that technology has a much slower refresh rate than traditional Braille displays and causes them to be much louder.
I'm sure this isn't as difficult for people who use these tools day-in and day-out. But it was an eye opening experience for sure.
In his words, "You got really good at checking your code, because if you made a mistake, you had to wait until the next evening for another time slot."
It stuck with me because it boggled my (privileged) mind how adaptable people and their brains are to just about any scenario you can dream up.
It boggles my mind imagining the discipline that would be required to maintain all this state purely in one's mind.
The book https://en.wikipedia.org/wiki/Metaphors_We_Live_By is a seminal work on this.
From the more mainstream ones, The Last of Us 2 has famously implemented accessibility. I haven't played it, as it's one of the only games for the PS4 that is accessible, but people are saying that it almost plays itself when accessibility is enabled, taking away part of the enjoyment.
Other mainstream games are getting accessibility mods, Hearthstone has a really great one. Audio Quake, an accessibility mod for Quake, was also quite popular back in its day.
Text based games, from Infocom's interactive fiction to MUDS and MOOs are also pretty accessible, a significant portion of people still playing them are blind.
I don't envy anyone trying to solve this problem, seems next to impossible to do a live action game above a certain level of accessibility. Just the time you have to communicate what's on the screen (much less being able to quickly communicate what's on screen) is so tight on a shooter for example. Found a neat video [0] of TLoU2's accessibility features.
There's an episode of Person of Interest that provides at least a possibility here: "Let's try an ascending tone cue for right, descending for left.". The tone then switches to beeps when on target.
Feels odd sharing a youtube link in the context of this post, but if anyone wants to see/hear the scene I'm talking about it starts at 1:21 here: https://www.youtube.com/watch?v=cHIo96yBf70
(Just for a bit of context the character doing this isn't blind, but these cues are helping her shoot people through walls. The episode is the second season finale, titled "God Mode".)
I wouldn't presume to speak for others with a different experience from myself (and it does seem [1] like some blind users really like what TLOU2 had to offer), but as a fully-abled gamer with limited time, even I sometimes choose to watch a streamer or even a YouTube summary in cases where I'm interested in the story or whatever but don't feel up for playing a thing myself. I wonder how this option stacks up against what TLOU2 was able to deliver.
[1]: https://caniplaythat.com/2020/06/18/the-last-of-us-2-review-...
http://www.roguelikeradio.com/2012/10/episode-48-designing-f...
So Doom for echo locators not yet possible.
https://en.wikipedia.org/wiki/Head-related_transfer_function.
The only reason my spelling is as good as it is is the fact that I used to listen to English text with a Polish speech synthesizer for most of my life, as I was too lazy to switch languages. Polish is (almost) phonetically perfect, so I was hearing things almost exactly as they were written. This made my spelling much better than that of most blind Americans. Words like cystom (system), keybored or even polotission (politician) can sometimes be seen in the blind community.
The built in mobile screen readers are not hard to setup. Enable in the settings and you can play around with it to grok how it works and how to navigate the UI tree with it.
Lowest hanging fruit always seemed to be making sure all the controls you wanted on your page were reachable with accessibility navigation (ie tabindex/focusable) and that the spoken labels were sufficient without sighted context.
This means if you do anything good you will need to test on different screenreaders, I like https://assistivlabs.com/ for a service to allow you to do screenreader testing also because the developer who runs it is really helpful.
It also means the best ways of doing things tend to be the ones that have been around longest because every screenreader / browser combo has implemented different parts of newer specifications - that is to say it will feel like your chosen screenreader is Chrome, but all the other ones are IE11.
I personally find that what helps you most about understanding when a site is not accessible enough is, after you have read a bit about problems people with screenreaders have, imagine using your site if you were blind.
Because you are blind things happen atomically, you do not have an context clues that you can see about what something is, so actions you can do on stuff should probably say not just what they are doing - like a button that says Delete - but what they are doing it to - like a button that says Delete and has an aria-label that says Delete user account. Really - being willing to sit still for 20 minutes looking at your site and thinking but what if I couldn't see will probably help you find a bunch of obvious problems.
Also when you have a sort of good fundament to your sites assistive usage, it means that things will be a lot easier when you do start testing on different screen readers.
on edit: obviously when I say because you are blind things happen atomically, I mean that in the context of using a screen reader on a webpage
Yes, I'm hoping to acquire this mindset. What I'm building is quite simple, almost crud like in terms of the UI. The issue is I don't feel I get the mindset just yet. I understand speech is linear, and I assume the order mainly comes from how it's laid out in html (as opposed to position). But how do visually impaired navigate the items in this big list, intuitively and quickly? I assume focusable elements are critical, but how about the the rest of the content hierarchy? A row in a table doesn't tell me anything if I can't see the header simultaneously - for instance.
https://www.w3.org/TR/wai-aria-practices/examples/table/tabl...
using voiceover you read the table it tells you the column names, probably in reading a table you would probably first read all the headers so you know what the table is dealing with - here these are first name, last name, company, address.
If you know what value in the table you are looking for you would go to that column, for example last name the second column, then navigate down with the voiceover key combination and the down arrow to get to the row you are interested in - row 2 James I'm looking for sara james so let's go to the first name column, then you could use voice over key combination and left arrow to go to the first name column and see it is Sara, then you read all the contents of that row to find out Sara James, Acme, Inc., 123 Broad St.
Obviously you need to remember the headers in this way of working, so if your tables are really complicated and have a lot of data in each column it might be nice to put a hidden screenreader only message in there that says Contents for First Name Column or something like that. But in this simple case I think it is reasonable to assume people will remember the column headers.
on edit: this is from a developer who is not blind however, so a blind user may have more efficient ways of working than me. Also note, many screen reader users are not completely blind or have some other disability, like dyslexia, which makes using a screen reader useful for them. A dyslexic user may be able to figure out the headers of the table, but if the individual cells have a lot of content the screen reader will be useful for them.
Not sure if many developers miss this:
Look at your UI in black/white. Plenty of folks are colour-blind of one kind or another. If your UI works in black/white, it'll probably work for any kind of colour-blindness.
See also https://www.youtube.com/watch?v=-IhQl1CBj9U for something focused on games, but with broader applicability.
Another good resource is the GDS accessibility standards: https://www.gov.uk/guidance/guidance-and-tools-for-digital-a...
It's tailored towards creating services within the GDS portfolio of services but there is good advice in there too
Step 1: Use a desktop PC. Step 2: Unplug your mouse.
Now learn to use your computer and then your site.
Windows is basically 100% usable by keyboard alone, and that basically is how all blind users use it. They can't see a pointer so pointing devices are useless.
I am Very Old™ and I learned Windows in the 1980s in a company that sold Macs as well as PCs, so it didn't have any PC mice. So I learned to use Windows with keyboard only.
I still can, although it's harder now. But I now run mostly MacOS and Linux.
Windows works very well with the keyboard and I sometimes amaze people by how fast I can move around and do stuff, because I don't take my hands off the keyboard or point and click much. I use the keyboard to run programs, move and rearrange windows, close windows, select and copy and paste, navigate forms etc.
All standards-compliant Windows programs use the same keystrokes to do this and they work everywhere. Learn them and you'll become faster anyway, _as well_ as improving the accessibility of your sites by becoming familiar with how blind users must access them.
HAH! Love it. Side note: I constantly make fun of the English phrase "I see what you're saying", meaning "I understand", often swapping it out with "I hear what you're seeing", sometimes swapping it multiple times in one sentence. People almost never notice unless I follow it up with "I smell what you're feeling" or "taste what you're smelling", because this creeps them out.
Heerlijk (meaning delicious) can also be used. I found a gravestone with the translation: “we thank you God for your great deliciousness”.
In that context 'heerlijkheid' has nothing to do with taste words, it simply means 'glory'.
But "heer" in Dutch is either a (human) lord or God, so "heerlijk" means lordly or godly, and over time this became more general.
Much the same word exists in German, "herrlich", but it means "beautiful" or "splendid". Same idea though.
My partner is a native speaker and I'm not, yet he often asks me how to spell.
Like chord keyboards.
Or maybe some other less wide spread but also less complex to use phonetic input methods?
And I am perfectly capable of doing this with my eyes.
But: I would never assume anything about the experience, challenges and abilities of the OP. I was fascinated by the depth of the recommendations and was reminded that I very much need to work on making my sites more accessible.
But I would personally probably refrain from asking if they couldn't just keep a paragraph of text in memory. But that is just me.
On the Mac, this is not an issue. The whole recovery environment is 100% accessible, at least on M1. I think it was more problematic on Intel, but you could still figure it out.
Yes, there are multiple screen readers.
Screen readers do not need or particularly use a monitor; monitors are for sighted people.
Screen readers read what is displayed at and following their cursor. This means screenreader users need to learn to control a system with 2 cursors: one for entering text, and a different one for reading it.
People asking about multiple screens for blind users are basically asking which colour of monitor bezel blind people prefer. This is not a question. It's irrelevant.
Some OSes will not boot or will not display a GUI unless they detect a monitor, although there are HDMI dummies that can fix that. So, some blind users may have an old monitor connected, just so their OS will boot.
Is there a community for blind developers? I could see that being a helpful resource.
Would you also appreciate an easier way to find replies to your own comments?
I'm not the original commenter, but I am a screen reader user who works in accessibility.
Unfortunately, I don't have too many good examples; the problem of hierarchical commenting systems being difficult to navigate is common across the web. There is a Reddit client for iOS, Dystopia[1], that does this extremely well for users of the built-in screen reader, VoiceOver[2], by allowing entire threads/subthreads to be collapsed and/or skipped over. On the web, you'd want to look into using hierarchical headings, nested lists and the like, to allow the structure to be conveyed semantically. HN is inexcusably bad at this, as there isn't a single heading anywhere on the site.
[1] https://www.reddit.com/r/DystopiaForReddit/ [2] https://support.apple.com/guide/iphone/turn-on-and-practice-...
That’s unfortunate! Clearly blind people are the most qualified to work on one specific frontend job: accessibility.
The fact that it’s extremely hard to automate accessibility testing in a meaningful way would make it a full time job at most places that take accessibility seriously.
Sighted developers and QEs will miss testing elements if they aren't aware they should be there.
This is highly variable. As a screen reader user who works in accessibility with a software engineering focus, I don't consider a test to be complete if I've only evaluated what the page exposes to the accessibility API. Assessing the rendered DOM by hand, testing on different viewports where controls may be slightly or completely different, etc., are just as critical to the testing process as trying to simply use the page. But, I recognise that there are many accessibility testers out there without such a technical focus, and it is true to say that they may gloss over something if it is completely missing in the accessibility tree.
Have any examples of issues while doing DevOps? For that type of work, in my own perception, I deal 100% of the time with text (be it error messages, or automation code).
"Ask HN: I'm a software engineer going blind, how should I prepare?" https://news.ycombinator.com/item?id=22918980
Before moving I spent a lot of time working with various blindness organizations in the states...they move very slowly and unfortunately I got basically nowhere before moving. Going to pick that up again here though.
I'm still working on making changes to my dev workflow, but besides a good screen reader I'm not sure much needs to change in that respect as the tools I use support screen readers.
Overall I've just focused on figuring out a longer plan for my life and focusing on achieving those goals instead of just drifting on a tech salary. This whole thing has really changed my perspective on things.
Emacs is great but it's not a panacea. There are some tasks for which it is ill-suited.
Sure if you find a piece that does a particular task in a blind friendly way go for it, but being a part of the modern world is easier with emacs+emacs speak than any other single tool I know of.
Back when I used email a lot every day for my job, I did all of my email processing in emacs. I'm somewhere else now in a different role, for this I use outlook because it was provided and it is unilaterally worse. The search is worse, the usability is worse and the speed is worse. What exactly about it is awful?
> web
Yes, the web experience is very bad. No argument there :)
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.
I’m not going to lie though, I do get a bit of a Monty Python vibe from the “rivalry” with the AFB.
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.
I have used it in the past for hands free coding, there is a steep learning curve but once you get comfortable with it many things can be done faster by voice than with your hands.
Be aware, using your voice all day can be hard on the vocal cords.
I'm looking at Talon at the moment but I'm disappointed that it has no clear way to opt out of user metrics and the first thing it does on launch is download blobs from the internet without explanation. It's not clear if it even can work offline at all. For a program that listens to everything you say that is a bit disconcerting (especially in the context of sensitive work projects). I'd like to just pay for something and never have it connect online, bar manual updates.
The blob it downloaded is probably the speech recognition model. I'd ask on the slack if you're concerned, aegis has worked really well with me.
I searched and could not find it anywhere (v0.2.3).
I'm creating a sort of serenade-like system in Talon, since I want it to be open-source and have tight integration with Talon. So I'm curious what the highs and lows of serenade have been for you.
What I love is that it feels so natural to use. It understands the context of the code, which means you don't have specify exactly where to move the cursor, or what kind of casing you want on variables. It automatically does what you want it to. I also love that everyone has the same set of base commands. It makes it easier easy to share information and help each other out. Oh, and the browser extension for Serenade is such a life saver. I'm mainly a front end web developer, and it's so easy to navigate the UI with that browser extension as I'm developing.
Assuming by engineer you mean a software engineer who uses a computer all day.
If you have the ability via your employer or individually to purchase LTD, you should really do so.
Universal healthcare also works due to this assumption; everyone is paying into it, so the cost of the most expensive (the sick) is balanced by the cost of the least expensive (the healthy). As the former outpaces the latter, the premiums for everyone grow.
It's also why the ACA in the US mandated participation or a fine; to make it more affordable the healthy need to also be paying into it, but the healthiest also tend to be the youngest, and the least likely to buy insurance, whereas the older and sicker would all buy in (and now have to be covered), and that would make the premiums untenable (leading the moderately healthy to decide not to buy in, causing an even bigger issue, etc etc, until it doesn't make sense for anyone). And why prior to the ACA, you needed a physical, and pre-existing conditions generally led to you being excluded.
But, while the US has changed with regard to health insurance, it still is the case that if you want LTD as an individual, expect to have questions about your health, if not an actual physical, just like life insurance does, and to have it denied, or have insanely high premiums, if you are looking likely to need it.
For me in my company I pay less than $25/month, I know co-workers who opt out…I honestly don’t understand that logic.
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.