Stories from the Trenches: What I’ve learned from Working as a Blind Developer for a Sighted Dev Team

Introduction

Before I can claim any familiarity with the material I am about to present, both myself and the topic at hand need to be introduced. This will set the stage for the later portions of the article.

I am a Dutch developer, recently graduated with a bachelor’s degree in IT. During my time as a student, as well as after graduating, I have worked for various companies as a back-end web developer who is slowly but surely also migrating to more and more front-end work, the technological landscape being what it is. I have worked with a variety of technologies, from C# to Python and from Rails to JavaScript.

I am also an accessibility expert, familiar with the usual suspects such as WCAG, ATAG and friends. What I mean by proficient in this case is that I have used these skills in a professional setting by performing accessibility audits on websites, web applications and desktop applications. I have also amassed theoretical knowledge by going through the Deque University training program which I can highly recommend if you want a firm grounding in accessibility fundamentals.

This proficiency with accessibility regulations is mainly a consequence of the fact that I myself require content to be accessible in order to be able to use it. I am fully blind, use a screen reader to do my job and walk the treacherous path of the blind developer. A path I will describe, as well as the various traps it contains.

This description will at times be factual, at times opinion-based. Most of the time, it will be the experiences of a single individual who writes code for a living without using his eyes to help him see what he’s doing. I am hoping this tale will shed some light on my workflow and the things I have to deal with to keep that workflow going on a regular basis. Finally, it will be a snapshot of sorts of all the things I’ve learned and am still learning about this process.

Starting your journey: getting a foot in the door

In order to work for a dev team with sighted colleagues, you obviously will need to get hired first. Making that happen means you need to hop over some interesting gotchas that may not be immediately apparent, which is why I dedicate a section of the article to it here.

Job hunting as a blind developer is an interesting activity. Just like anyone else applying to any job ever, it starts with a resume and in most cases a cover letter.

A question I initially faced was if I would immediately notify the company of my blindness or not. I’ve found that generally, it’s better to not do that because of the simple reason you put unnecessary emphasis on the blindness if you do. I am a developer with qualifications, experience and skills I have earned and worked hard for and those are the merits I want to be hired for, being blind, to me, is an inconsequential thing next to those skills, unless it can somehow be an asset to the position. This would for example be true for an accessibility-related position.

This has led to some rather interesting situations, from bewildered looks at my white cane or, later, guide dog, to hastily devised excuses to end the job interview prematurely. Although discriminating against someone with a disability is illegal, it is at times rather easy to disguise as something else, this is something to look out for. Fortunately, this doesn’t happen all that often but to not mention it here would be playing fast and loose with the truth. It is a careful balancing act in the best of cases; these days, I tend to mention my blindness at the very last moment when I negotiate a job interview over the phone, by stating I will be bringing a dog to the office and asking if anyone is allergic to dogs. Usually, the next question is a very understandable “Why?” and only then will I mention it, minimizing it as much as possible. Most of the time, this approach has given me at least a chance to come in for a first interview.

Other obstacles are mandatory screenings or assessments that are not accessible, these are generally standardized tests that cannot be deviated from according to the company, which generally ends the job interview procedure right there. Obviously, the issue can be forced but in the vein of creating a positive working environment this is really not something I can recommend. That has to do with the above mentioned emphasis on your status as a blind person; the more you make an issue of it, the more importance it gains for the person considering your job application.

What follows is generally an almost scripted procedure. The job interview goes off without a hitch in most cases, but gains an extra component I like to call the “Monkey show, Monkey do” portion. This part of the interview is usually preceded by a question like, “You can probably imagine why I ask, but … how? How do you program without looking?” At this point, I explain about screen readers, the blazingly fast rate they spit out information at and I usually get out my laptop to give a bit of a demonstration. I usually get stares of amazement and, once, I was even applauded for. Although that is of course very flattering, being stared at in admiration for doing something that is second nature has a tendency to get old from time to time. Obviously this is nothing personal; it’s just possible that you are the third person doing so today. Answering the same questions over and over certainly falls in that same category as well. As a result, I actually wrote an article to answer some of the questions I often get when it comes to being a blind developer. Fortunately, both this demonstration as well as this momentary period of being stared at usually doesn’t last very long and I’ve found that doing this makes it a lot easier to explain why something is or is not a challenge further down the road. I therefore would say that being put on display like that, although sometimes uncomfortable, is very much worth it in the end. After all, the reactions are understandable. I am doing something a lot of people can’t even imagine doing without sight.

Picking your tools: The constant Struggle for the constant Juggle

For various pursuits, you require a set of tools to be effective. Climbers will need rope, anchoring hooks etc. And programmers require tools to program, test, collaborate, share and look up information etc. Unfortunately, this is where a lot of people quit, perhaps even more unfortunately this is very understandable. The amount of work to get a decent stack going that works for your use case, next to working a normal 40-hour work week, can be very overwhelming.

The operating system is the first hurtle; a lot of dev teams here in the Netherlands use macs exclusively, which is very understandable. Sadly however, the accessibility APIs available to the Mac OS X screen reader, Voiceover, are in a lot of cases inferior to those in Windows.

The amount of keystrokes required to perform a task on the Mac is often higher than on Windows, OS X being a very mouse-oriented operating system. Finally, the screen reader itself lacks a lot of the convenience features and customization options of it’s Windows counterparts. In an industry that is supposed to be equally accessible to both the blind and the sighted, these shortcomings translate into serious productivity hits in comparison to my sighted colleagues. This can be stressful and requires some understanding and flexibility from my colleagues at times. Generally, a lot of tasks can be performed with near equal speed as a blind person, once familiarity with the codebase and tools has been achieved. Achieving that familiarity however, can take time. Especially if tools are not as accessible as they can be, you lose precious time wrestling with a tool that is supposed to help you in your work, but rather, hinders or even blocks you entirely. Fortunately I have usually been met with understanding and, a lot of times, curiosity about the shortcomings from my sighted colleagues. This isn’t something to depend on though; when a lot of work needs to be done in a short amount of time, every productivity hit is in a sense one too many. To alleviate these problems as much as possible, it is paramount that you know every little shortcut and trick of the trade in your tools of choice to shave off time wasted on actions you repeat all the time. Macro keys, shell aliases, editor extensions that give you more keyboard shortcuts are the name of the game. This however, is not possible when the tool you are forced to use is inaccessible and gets in your way.

This notion of tools that are supposed to help you getting in your way instead is an important one. Where my sighted colleagues often use graphical tools to manage certain aspects of their jobs, these tools are often inaccessible. This requires me to , often on the spot, figure out some kind of workaround to still perform the same task with some modicum of efficiency. For a graphical application, this might be a command line equivalent. A website might have an API. Sometimes, a second graphical tool might work better than the de facto one. Constantly puzzling out alternatives for inaccessible technology is a constant part of the job when you do it with your eyes closed. Getting the freedom to bring your own tools is very important for that reason.

I’ve rarely seen tools being enforced because developers generally have a strong preference for their own workflow, but the places that insisted on doing this gave me such a hard time that such a regime is now a deal breaker for any future contracts I take on. It is that important.

Your first thought might be to just use Windows if OS X is less productive. In an ideal world, that would be a viable solution. However, especially in older codebases, dev teams have often devised little hacks to make older code run on their newer hardware/software that shouldn’t even be running anymore in the first place. These hacks are OS-specific, often hard to replicate on Windows even while using the Windows Subsystem for Linux and can take weeks or more to get working, it’s often not worth it.

Right now, for that reason, I am running a Windows 10 virtual machine within VMware Fusion on the Mac. I am forced to use two operating systems at once to get my work done. Windows holds my web browser, my code editor of choice and various other tools I use to increase my productivity. Google Chrome, VS Code, a decent PDF reader, an office suite for working with DOCX and XLSX files, basically all real applications run on the Windows VM, making the OS X part more of a server that just hosts the application code. This is a good example of the freedom of to use your own tools I referred to. Nobody else in my team runs the same setup I do, but doing this has generally been met with understanding and support from my colleagues because they can see I can get work done this way.

Accessibility, especially in dev tools, can be incredibly hard to defend. Often you are not being taken seriously when you ask for what should be a basic feature. It is not on the roadmap, developers can’t be spared to work on it, it doesn’t have priority, etc. Are reasons for not fixing a tool’s accessibility almost like clockwork. Other times, promises are made for fixes that never materialize. I would love to see this improve, and have had the pleasure of seeing it happen now and again. It is still a problem that keeps coming back though and as developers, me included, we should do better.

My sighted colleagues take a lot of tooling for granted. In a .NET team for example, it is rare to see a developer that isn’t using ReSharper to boost their productivity. Ironically, this extension for Visual Studio, itself quite accessible, uses a lot of keystrokes to do what it does. You would think that would make it an ideal tool for a blind developer, who only uses a keyboard to code. However, the output of this extension is more often than not inaccessible. I have been hounding Jetbrains for years to get them to fix this tool’s accessibility, which even at the time of this writing is abysmal. I have been impolitely dismissed, ignored and finally made promises to, so far unfulfilled. This unwillingness to fix what is obviously a problem that has been there for years makes me hesitant to commit on a .NET-based position. Even if the problems get miraculously solved, the track record of leaving it unsolved for so long would make me wonder when it’s going to break again.

In one of the first dev teams I worked with, Postman was used heavily to test API endpoints the back-end developers created. Postman has a number of glaring accessibility issues that make it hard to use with a screen reader. For a perfect example of unfulfilled promises, have a look at this github issue. Observe that the issue is still open after almost 1.5 years and promises are made but not being kept.

Accessibility is often an afterthought, something that is undeniably proven again and again. Slack, sadly, is a good example of this. At the end of 2016, this was the status of Slack accessibility. We are definitely seeing improvements in that space, something this article aptly demonstrates, but the amount of time all of this takes is incredibly high; months, at times years that people using a screen reader cannot adequately access resources their colleagues have access to. This kind of deficiency can and does cause people to lose their job because they just can’t keep up with the communications within the company they work at.

The tools mentioned above (Resharper, Slack, Postman etc.) are key players in their chosen fields. Not having access to these tools hamstrings you as a developer and forces you to spend cycles you should be spending on getting work done on finding workarounds and alternative tools instead. This is wasteful, tiring and shouldn’t be necessary, but it is and it is one of the core skills I’ve had to get very good at to keep up.

As time goes by, I will say that there seems to be a downwards trend of this being necessary, though. Efforts of Microsoft, Apple, Google and other big players are making more and more people aware of this almost constant battle for equal access to productivity. By no means are we out of the woods though, something that was quite clearly demonstrated by the Gutenberg WordPress debacle that is currently raging through the accessibility community.

Blind people are a niche market to software and web developers. Blind developers are a niche market within a niche market. Blind developers who keep at it, become productive and hold a full-time job are sadly even more rare. This can and should change, but until that happens the fight for accessible developer tooling is one you fight on your own. I hope it is a fight we won’t have to fight in the future, I will do my best to contribute to that goal.

Odds and end

I want to end this article on a positive note. The fact that I am still in this field, the fact I hold a full-time job as a developer brings me a lot of happiness even through all the seemingly constant obstacles. I’m happy I can contribute to a great team of colleagues that treat me as an equal and think with me when I run into something I am having trouble with.

I want to emphasize that even though the field of Computer Science is not free of obstacles, people can thrive and are thriving in CS-related jobs. The struggles described above are certainly true, but compared to other fields they are at least to a large degree manageable. I doubt that I will write an article any time soon about my career switch to a surgeon, a fighter pilot or a professional baseball player, but then technology might yet surprise me. For now though, I’m happy where I am and have a great team around me.

I am often asked for my opinion when it comes to the effect on the accessibility of the product we are working on. My opinions definitely aren’t always going to cause things to change, but I’m glad I am at least able to make people aware of the importance of accessibility and what will happen when it is being disregarded. I am, after all, a living breathing example of just what happens when a tool is not or no longer accessible. The WordPress article linked to above sends this message very clearly; a tool that has been very usable and accessible for years is now nose-diving. This is something that can happen to any tool a blind developer depends on, the Russian roulette of the business so to speak.

By writing articles like this, by giving talks, educating developers and by experimenting with new tools, new techniques and new methodologies I hope to stay ahead of the curve. By writing down my findings, I hope to teach others the tricks of the trade I found out by trial and error so the threshold to this field is lowered for screen reader users.

The main goals of this article align with many, if not all of those goals. I hope I have given you a glimpse into both the struggles as well as the positives of a blind programmer. I hope I have pointed out that even though doing this is possible, we can and should improve the experience immensely. I hope I have sparked the readers of this article to think, really think, about the consequences of inaccessible software and I hope I have shown off that even through all the obstacles, it is very possible to become good, even great in this field once you achieve escape velocity.

In light of the positive note I was just referring to, I want to end this article by mentioning two huge accessibility wins that are perfect examples of how we have done better, both of which I have been an honored contributor to. For learning how to code, a lot of the more interactive resources out there like Codeacademy are not very accessible. This has to do with various components that are used in these projects not being accessible. Fortunately, this is already being worked on. One of the resources that has been gaining a lot of traction over the last few years is FreeCodeCamp. This initiative used to have some rather severe accessibility issues which very recently have almost been completely fixed and overhauled, making the platform very viable for screen reader users who want to learn how to code.

This has a lot to do with the Monaco Editor which is a very accessible web-based code editor and is in fact the editor component Visual Studio Code uses. This editor, when it came out, was literally completely inaccessible. However, in a relatively short time this was not only fixed to a large degree, but now makes projects like FreeCodeCamp accessible by default because they use the same component. This is the way it should always be, this is what I am hoping to see more of as I keep at this. And with that, I think it’s high time I get back to programming.