Headaches for a Blind Developer

Regular headaches for a blind developer.

It is a testament to the 21st century that despite being unable to see, I can write, and put out my thoughts for hundreds of readers to see and read. (Not millions, I know my place.) Having said that, there are a lot of pain points that are left to address. In this article, you will learn about the things that give me regular headaches as a developer. Also, these things are pretty much my own experiences. If you encounter other blind developers, they’ll have their unique list. Though I’m certain some items will overlap.

“You haven’t developed a thing worth a damn. Stop calling yourself that!”

… I’ll just move on.

People.

Look, I admit that I’m not a people person. I don’t like to meet a lot of new people, and constantly answer them about my life, or be treated like some unique creature who somehow escaped from a zoo. But above all, I don’t like when despite my explanations, a person working with me just refuses to understand how I do things, but also imposes his view on me.

Let me clarify this a little. I have two mentors so far in my programming journey. The second mentor was really difficult to handle for me, because of various things about which I have talked in this article, but the most important of all, he refused to understand how screen readers work.

I get that. no one has to know how these technologies work on a deep level because a lot of people are just not going to work with a blind person. But when you are regularly working with a blind person for a year, one would think you would try to understand how they do things, to speed up the work. But this guy never did that.

He constantly asked me about the things that a screen reader is unable to tell, for example, what is in an image, or some things which it can tell, but ignores because it is not necessary, for example, the position of the text alignment, the color of the text, and animation. It is possible to get these things, but they don’t serve a purpose, so most blind users just ignore this information.

He also didn’t understand that screen readers read in a linear top-down fashion. Meaning, it doesn’t matter how you put things on a webpage. It will be read top-to-bottom, line-by-line. This is actually by design, for again, a blind user is going to get confused if you try to describe things as it is on the screen.

I also admit that this point comes across as rather petty. But I decided to include it here all the same. Don’t blast me in the comments below! (Or you know, blast me all you want. let’s see whether I get any comments or not.)

Tooling.

Here, interfaces are a problem. Usually, a lot of programming tools offer two interfaces. One is GUI, other is the command line. Gui is inaccessible with screen readers. Here are a few examples. The gui of Git and gui of CMake.

IDEs and text editors are also hit-and-miss. While DR. Racket is completely inaccessible, the likes of Visual Studio and Eclipse do work. However, they tend to break functionality at the worst possible time. not to mention, working with sighted developers can be a headache. “You see this?”

“I can’t.”

“Yeah, but it is right there.”

“Where, describe to me.”

“The little icon of something something.”

“I don’t see the icon.”

Literally every conversation I had while working with an IDE with a sighted developer. The worst breakage of functionality happened in 2010, of which older blind developers warn me about it still to this day. Things were running fine, that one day Microsoft broke the accessibility of Visual Studio completely. Imagine waking up one day, and finding that the tool on which you relied so much yesterday, is completely unusable to you now.

Of course, there is another issue, that is the speed. seriously, even at the beefiest machine, these IDES run so slow. This also causes problems for the screen readers, since when the system is barely managing to crawl, it also crashes the screen reader.

The command line is great for screen readers, as long as there is no ASCII art in there. Because to a screen reader, those are nothing but a string of symbols. It doesn’t paint a picture with those symbols. The biggest reason is that the command line has only text. Text as input, text as output. Not to mention how fast they run compared to a graphical IDE.

However tracking down documentation can be such a headache, especially with the Visual Studio command line. I think Microsoft hates it or something. However, documentation for Git and Power Shell is great.

Things online aren’t any better.

One might think that online tools like playgrounds or repl.it would be better.

Surprise, surprise. they are not. Online editors are even worse than the editors on desktops, I often end up copying the code from there, work on it offline, and then copy it into their editors for code challenge sites.

I was especially disappointed with the repl.it. because it meant I couldn’t play with their scheme implementation for SICP, and I couldn’t use it for Free Code Camp either. This has been the case with a lot of online services. They offer great functionality, but they aren’t even willing to incorporate basic accessibility in their services. Chess.com is the same, and now repl.it also did the same thing.

Now, contrast this with a Rust playground. Things are great here. I also get to see the config and even get to inspect the assembly of various flavors. So, I often wonder if it is possible on Rust’s playground, then why it is not possible here? I suppose it just comes down to the unwillingness to work on it. Anyway. that’s all for today. Tell me what you thought of these headaches in the comments, and I’ll see you in the next article.