Software development 450 words per minute

"Something's a little bit off here." That's what I predict your first thought to be upon seeing my cubicle for the first time. There's no screen or mouse in sight. Instead there's a guy hammering away on a keyboard, staring at seemingly nothing.

A picture of the author standing at a desk. There's a keyboard and a laptop with its lid closed.

It's only me, and my colleagues can assure you that I'm mostly harmless. I'm a software developer working at Vincit offices in Tampere. I'm also blind. In this blog post I'm going to shed some light on the way I work.

Are you blind as in actually blind?

Correct. I can perceive sunlight and some other really bright lights but that's about it. In essence, nothing that would be useful for me at work.

What are you doing there, then?

The same as almost everyone else, that is: making software and bantering with my colleagues whenever the time permits. I have worked in full stack web projects with a focus on the backend. I have also taken up the role of a general accessibility consultant – or police; depends on how you look at it.

How do you use the computer?

The computer I use is a perfectly normal laptop running Windows 10. It's in the software where the "magic happens". I use a program called a screen reader to access the computer. A screen reader intercepts what's happening on the screen and presents that information via braille (through a separate braille display) or synthetic speech. And it's not the kind of synthetic speech you hear in today's smart assistants. I use a robotic-sounding voice which speaks at around 450 words per minute. For comparison, English is commonly spoken at around 120-150 words per minute. There's one additional quirk in my setup: Since I need to read both Finnish and English regularly I'm reading English with a Finnish speech synthesizer. Back in the old days screen readers weren't smart enough to switch between languages automatically, so this was what I got used to. Here's a sample of this paragraph being read as I would read it:

And here's the same text spoken by an English speech synthesizer:

A mouse is naturally not very useful to me so I work exclusively at the keyboard. The commands I use should be familiar to anyone reading this post: Arrow keys and the tab key move you around inside a window, alt+tab changes between windows etc. Screen readers also have a whole lot of shortcuts of their own, such as reading various parts of the active window or turning some of their features on or off.

It's when reading web pages and other formatted documents that things get a little interesting. You see, a screen reader presents its information in chunks. That chunk is most often a line but it may also be a word, a character or any other arbitrary piece of text. For example, if I press the down arrow key on a web page I hear the next line of the page. This type of reading means that I can't just scan the contents of my screen the same way a sighted person would do with their eyes. Instead, I have to read through everything chunk by chunk, or skip over those chunks I don't care about.

Speech or braille alone can't paint an accurate representation of how a window is laid out visually. All the information is presented to me in a linear fashion. If you copy a web page and paste it into notepad you get a rough idea of how web pages look to me. It's just a bunch of lines stacked on top of another with most of the formatting stripped out. However, a screen reader can pick up on the semantics used in the HTML of the web page, so that links, headings, form fields etc. are announced to me correctly. That's right: I don't know that a check box is a check box if it's only styled to look like one. However, more on that later; I'll be devoting an entire post to this subject. Just remember that the example I just gave is a crime against humanity.

I spend a good deal of my time working at the command line. In fact I rarely use any other graphical applications than a web browser and an editor. I've found that it's often much quicker to do the task at hand on the command line than to use an interface which was primarily designed with mouse users in mind.

So, given my love of the command line, why am I sticking with Windows, the operating system not known for its elegant command line tools? The answer is simple: Windows is the most accessible operating system there is. NVDA, my screen reader of choice is open source and maintained more actively than any other screen reader out there. If I had the choice I would use Mac OS since in my opinion it strikes a neat balance between usability and functionality. Unfortunately VoiceOver, the screen reader built in to Mac OS, suffers from long release cycles and general neglect, and its navigation models aren't really compatible with my particular way of working. There's also a screen reader for the Gnome desktop and, while excellently maintained for such a minor user base, there are still rough edges that make it unsuitable for my daily use. So, Windows it is. I've been compensating for Windows' inherent deficiencies by living inside Git Bash which comes with an excellent set of GNU and other command line utilities out of the box.

How can you code?

It took me quite a long time to figure out why this question was such a big deal for so many people. Remember what I said earlier about reading text line by line? That's how I read code. I do skip over the lines that aren't useful to me, or maybe listen only halfway through them just for context, but whenever I actually need to know what's going on I have to read everything as if I were reading a novel. Naturally I can't just read through a huge codebase like that. In those cases I have to abstract some parts of the code in my mind: this component takes x as its input and returns y, never mind what it actually does.

This type of reading makes me do some coding tasks a little bit differently than my sighted colleagues. For example, when doing a code review I prefer to look at the raw diff output whenever I can. Side-by-side diffs are not useful to me, in fact they are a distraction if anything. The + and - signs are also a far better indicator of modified lines than background colours, not because I couldn't get the names of those colours, but because "plus" takes far less time to say than some convoluted shade of red that is used for highlighting an added line. (I am looking at you, Gerrit.)

You might think that indentation and other code formatting would be totally irrelevant to me since those are primarily visual concerns. This is not true: proper indentation helps me just as much as it does a sighted programmer. Whenever I'm reading code in braille (which, by the way, is a lot more efficient than with speech) it gives me a good visual clue of where I am, just like it does for a sighted programmer. I also get verbal announcements whenever I enter an indented or unindented block of text. This information helps me to paint a map of the code in my head. In fact Python was the first real programming language I picked up (Php doesn't count) and its forced indentation never posed a problem for me. I'm a strong advocate of a clean and consistent coding style for a number of reasons, but mostly because not having one makes my life much more difficult

Which editor do you prefer?

Spoiler alert: The answer to this question doesn't start with either V or E. (Granted, I do use Vim for crafting git commit messages and other quick notes on the command line. I consider myself neutral on this particular minefield.) A year ago my answer would have been, of all things, Notepad++. It's a lightweight, well-made text editor that gets the job done. However, a year ago I hadn't worked in a large-scale Java project. When that eventually happened it was time to pick between Notepad++ and my sanity. I ended up clinging to the latter (as long as I can, anyway) and ditching Notepad++ in favour of IntelliJ IDEA. It has been my editor of choice ever since. I have a deeply-rooted aversion towards IDEs since most of them are either inaccessible or inefficient to work with solely on the keyboard. Chances are that I would have switched to using an IDE a lot sooner if I was sighted.

But why Notepad++, you might ask. There are more advanced lightweight editors out there like Sublime text or Atom. The answer is simple: neither of them is accessible to screen readers. Text-mode editors like Vim aren't an option either, since the screen reader I use has some problems in its support of console applications that prevent those editors from being used for anything longer than a commit message. Sadly, accessibility is the one thing that has the last word on the tools I use. If it's not workable enough that I can use it efficiently, it's out of the question.

Do you ever work with frontend code?

You would think that frontend development was so inherently visual that it would be no place for a blind developer, and for the most part that is true. You won't find me doing a basic Proof-of-Concept on my own, since those projects tend to be mostly about getting the looks right and adding the real functionality later.

However, I've had my fair share of Angular and React work too. How's that? Many web apps of today have a lot going on under the hood in the browser. For example, I once worked a couple of weeks adding internationalization support to a somewhat complex Angular app. I didn't need to do any visual changes at all.

I've found that libraries like Bootstrap are a godsend for people like me. Because of the grid system I can lay out a rough version of the user interface on my own. Despite this all the interface-related changes I'm doing are going through a pair of eyes before shipping to the customer. So, to sum up: I can do frontend development up to a point, at least while not touching the presentation layer too much.

How about all the things you didn't mention?

There are certainly a lot of things I had to leave out of this blog post. As promised I'll be devoting a post to the art of making web pages more accessible, since the lack of proper semantics is one of my pet peeves. However, there's a good chance I won't leave it at that. Stay tuned!

Tuukka Ojala

Tuukka Ojala
Software developer, accessibility police, avid tea drinker.

151 kommenttia

Brian Osborne says:

Great post Tuukka. In addition to your writing, which is truly first-rate, you’ve given so much insight to the sighted people about what it’s like for a blind person to work with computers, quite apart from programming. My son is blind and tech-savvy, so I already understand a lot of what you’ve explained here (to the extent that a sighted person can understand these things, that is), but you’ve also delved into so many interesting details in the post, and in your responses, that I have learned quite a bit more.

I really hope that you post more, either here or in your own blog, because I think you’re seeing in the comments how much the sighted people are intrigued and enlightened by your writing. That’s how I take it, as a sighted person and father of a blind person.

Buc says:

Great article! Reducing the knowledge gap on how things work for a person that must approach technology in a way that differs from the most common one is extremely important. That worked for me and I’m grateful to you for this.

Could you use The vOICe for Windows’ screen sonification options to perceive visual layout? http://www.seeingwithsound.com/winvoice.htm For instance try mouse area sonification (function key F9) with negative video (function key F5) for a start.

Siim Põder says:

Tangential, but how much nethack and dwarf fortress do you play?

Tuukka Ojala says:

I don’t, actually, but I guess I should at least try Nethack just to say I have. In general I don’t play games all that much.

archatas says:

Very interesting and mind-opening article. Thanks for sharing your experiences, tools, and methods.

Dude says:

Поражен твоей способностью воспринимать на слух код с такой скоростью! Ты крут чувак, удачи тебе!

Just found this article and I’m very happy I did! 🙂
It’s been enlightening to read a story of development from a completely different point of view, with a twist on very important details and tips on how accessible software should actually be –and crafted– for blind people.
I won’t add questions (although I could have many), but I’ll most probably keep reading your blog posts, whenever you’ll have time to write them 🙂
Thanks for this!

Thank you for sharing this. You are an inspiration Sir.

What a fantastic story, Tuukka. Thank you for sharing it. And yes, please continue to write. Really looking forward to your dev insights. All the best!

How do you handle captchas on web sites?

Tuukka Ojala says:

There are some services like captchabegone.com which can solve captchas. Also, more and more sites are using Google’s “no captcha recaptcha”, the one that has the checkbox saying “I’m not a robot”. Captchas are one of the most annoying hindrances I have on the web and I sincerely hope all the picture-based ones would die yesterday.

Harry Tajyar says:

By far one of the most inspirational and memorable posts I have ever read on the Internet. I am the vice president of corporate development for one of the world’s leading touchscreen companies and would love an opportunity to pick your brain on how we could use your talent and experience in launching the next generation of touchscreen technology. Should you have the interest please call me at 818-926-5441 or email me with your contact information so we can begin a dialogue. We are a publicly traded company and I assure you your compensation package would be very much to your satisfaction. I look for to hearing from you . If I do not I wish you the best in all of your future endeavors and want to thank you for such a beautiful post.

Sincerely,
Harry Tajyar

pierogilove says:

Very interesting article ! Did you try emacspeak ? This seems to be a good all-in-one solution.

Tuukka Ojala says:

Yes, Emacspeak seems to be the best solution for speech users on Linux. However, I’m not sure whether it works as well on Windows and how well I can use it with braille. Emacspeak is something I’ve been meaning to experiment with for a long time.

Justin Avery says:

Amazing article and very grounding from a sense that I don’t spend enough time caring about how the websites I help build ‘appear’ to every audience.

Maxim Kim says:

As person I’m astonished! Amazing, Tuukka!

As software developer I smiled at “this component takes x as its input and returns y, never mind what it actually does”. Your mates must be very good at naming and following conventions. Your work requires more discipline from you which should pay back in results also.
Indeed, when we are at our best, working in the flow we abstract and have big picture of everything in mind (glass house). Could not think it is achievable without seeing the code, why not.

As business manager thumbs up to marketing and HR.

p5ic05i5 says:

I’m impressed! After a couple of listenings I got the hang of the 450 WPM english speech and could extract most information, but not all! What I kept thinking of throughout the reading is how much information do you usually juggle in your head to have the right model of the code base at hand. It also gave me another reason to enforce a clean, consistent style on my colleagues. Cheers!

Enis Bayramoglu says:

Hi Tuukka, thank you for this nice post. After reading through it, I was curious about your opinion on operator-heavy languages like Haskell and Scala. Do they pose a serious problem? Like when you come across a bind (>>=) operator, do you have to listen to “greater greater equals”, mind you it’s not uncommon to use operators with even 5 characters in Haskell.

Tuukka Ojala says:

Yes, “greater greater equals” is exactly how it translates to me. This is one of the reasons why a) it’s much more efficient to read code in Braille and b) why I’d rather have all my punctuation being replaced by short sound snippets, but this sadly can’t be done just yet.

Best luck in future.
Nerd pick – added lines in git are marked with green, not red

Tuukka Ojala says:

Damn! I knew I missed something in there.

Ville Hämäläinen says:

Thank you for giving a glimpse in your world. I was wondering do you use code folding or function outlines at all to get overview of the code?

Incredible what the human brain can do! One of our engineers recently did a bit of work to make our content more accessible, would love some comments or suggestions or maybe even pull requests! http://artsy.github.io/blog/2017/08/29/Making-Artsy-Editorial-Accessible

Tuukka Ojala says:

Thanks. I’ll have a look at it.

Can you help me understand how you process 450 WPM English? I just can’t parse it no matter how many times I listen to it at this speed. Are you really able to internalize any arbitrary text at 450 WPM?

Tuukka Ojala says:

Yes. Start out with a rate you can understand. Then just gradually increase it, making sure you never go faster than you can handle. That’s how everyone I know has done it.

KAMAL IQLAAS BIN ISMAIL says:

I cant code better than you. Well, not yet at least. Thank you for the inspiration. Love from Malaysia.

James Coyle says:

I think the hardest thing for people to get their head around is how you manage to retain what is going on in a particular section of code. For a sighted developer like myself it’s not really an issue as a quick glance around the visual structure with all of the helpful code highlighting is all it really takes to find a particular section and/or discern what the code does.

I personally can’t imagine having to do that from memory (partially because I’m unable to actually visualize things properly). I’d assume not being able to see means that you have become very proficient at memorizing larger amounts of data and I imagine that really helps to speed up workflow. I can remember general structure and I’m really good at picking out those patterns when scanning the code for a certain method etc. but I can’t remember the details of implementation so probably waste a few seconds every time I have to read a line to remind myself what it does. That does however mean I tend to comment code well.

The indentation aspect is also pretty interesting. I personally feel that development teams should be using automatic code beautifiers anyway. Indentation in saved code is pretty pointless so personally I feel that the text editor should take a minified file and display it to the developer’s preference for editing and then re-minify it on save. That would also prevent any arguments over which way to lay out the braces, where to add whitespace, and the tabs or spaces debate.

Tuukka Ojala says:

I actually like to visualize things in my head which may be an advantage in this case. Also, when working with a large code base, I’m not even trying to memorize all of it. I have this broad map in my head of what each of the components do but I don’t really care what happens inside them. That’s why clean coding style is such an important thing to me: having small, pure functions makes it very easy for me to forget about the things I don’t need to think about, where as if I’m working with a >100 loc function that does a ton of processing I have to keep a lot of irrelevant information in my mind. (And before you ask: I love functional programming.)

As for saving minified files: that would be a no-go for me, since parsing those files would effectively require a plugin, which would force developers to use only the editors that had one. If all the editors that had this plugin were inaccessible I couldn’t work in that project.

Jii says:

Toi lisämotivaatiota hoitaa omia töitä paremmin. Mikään ei ole tekosyy, jos tahtoa on.

lays147 says:

Hi, Tuukka
This is the first time that I read a blog post about a blind developer. I feel shocked.
My definition of accessibility was really redefined after read your post.
Thanks for sharing your experience, and give to me a feel of how your life as a developer is, and for adding a lot of light on how I develop my softwares.
My best regards,

Matthew Aho says:

You are incredible! Thank you for this write-up, as someone who works primarily on small teams, I’m very guilty of making accessibility a lower priority. I think reading this will stick with me and change the way I operate.

Tuukka Ojala says:

That means I’ve done my job well. Thanks.

Thank you so much for this enlightening post. This makes me feel we, as developer, should spend more time thinking about how accessible our work is. Do you have in mind a fast and effective way to test and improve a react application for better accessibility?

Tuukka Ojala says:

I’m not that familiar with automatic accessibility auditing tools, but Chrome has a set of “accessibility developer tools” built in which let you evaluate the accessibility of the opened page. I know tenon.io is also being used a lot. Worth a try.

genechase says:

About 12 years ago I was teaching Computer Programming 1 using Java and the IDE JGrasp. A blind student wanted to take the course. He used JAWS as his screen reader. JAWS did not work well with any of the IDEs that I could find. I ended up using Visual Basic for him, which despite its name worked with JAWS.

One project of the course was to create a picture demonstrating mastery of loops and subroutining. For him I substituted a project about creating a musical composition demonstrating the same. It worked well. And my student and I both had fun.

Thanks for this neat post, which my vim-loving son pointed me to.

Tuukka Ojala says:

Why wasn’t an all-purpose text editor like Notepad++ an option? Sure, there’s no autocomplete or class browser but it lets you write. Believe it or not, that’s how I did all my Java courses in the university. I even wrote a couple of Android apps that way.

Anyway, you had a chance to either show your student that programming can be just as fun and rewarding for him as it is for the sighted, or show that it’s only going to be a huge accessibility struggle not worth pursuing. You used that chance well. Thank you for that.

lmn says:

Fascinating post! Thanks for writing it, I enjoyed reading it.

I recommend you check out Cmder for windows, it’s a unix-like terminal app which can be pimped out to do more or less everything a linux terminal does. It would make an excellent replacement for “living inside git bash”, and I swear by it.

Quick question: how fast do you type?

Tuukka Ojala says:

Thanks. I’ll have a look at it, although there’s nothing I would particularly dislike about Git Bash.

I have never tried measuring my typing speed. However, I’ve been touch-typing since the age of 8 which probably makes me fairly fast.

This was useful for me to learn. I attended a Scala conference this Spring in Lisbon, LX Scala, and one presenter was a young blind man who was also an active coder and I was intrigued as to how he managed. I would not imply that he uses the same methods as described here but at least I have a better sense as to how it can work now.

Arseny says:

Hello. You are awesome, thanks for sharing your story.

I wanted to ask a question on IntellJ IDEA as it is my favorite IDE. How happy are you with it? Also, how many features of it are you using? Did you try to check everything from the productivity guide (Help -> Productivity Guide)? Is Search Everywhere useful?

Tuukka Ojala says:

I didn’t even know about that guide until you mentioned it. I had to learn the basics of IntelliJ very quickly so I just picked up the features I needed. I’ll have a look at that guide to seee if there are any gems I’ve been missing.

Code navigation features are the ones I use the most, namely jumping between functions, code blocks and definitions. Those are huge productivity boosters for me.

oooooohblog says:

some friends of mine are developing an open source braille e-reader, the plan is to make it the same price as an ipad http://www.bristolbraille.co.uk/

Tuukka Ojala says:

I’ve been watching that project since its early days and it looks really promising. If they could make this work as a multi-line refreshable braille display that would be fantastic.

Oleg says:

Please, read that: https://www.slideshare.net/olegmilyoschin/visible-world-annotation

Tuukka Ojala says:

Thanks, this looks fascinating. Has someone made a prototype of this concept?

oooooohblog says:

i have forwarded this page to them, i am not sure what their plans are, i thought canute was going to be a straight e-reader, but it would make sense to make it usable as a display too,

and it looks like they are planning to do that

http://www.bristolbraille.co.uk/specification.htm

canute is developed by volunteers, they work for 50% of their normal rate, I don’t know if they need any additional help at the moment, but if you’re interested in getting involved in the development you could contact them.

Thank you for this great text, explains a lot of what non-bind people do not see. I am heavily impressed by the 450 wpm and cannot even imagine how you visualize code in your head. Respect!

One thought that came to me is, if something that can render the screen in Pin Art (short:
“a boxed surface made of a crowded array of pins that are free to slide in and out independently in a screen to create a three-dimensional relief.”, see https://en.wikipedia.org/wiki/Pin_Art detail) could help you visualize where information on a screen is; thus render a screen (ignoring images if possible), would give you a physical relief version of the screen thus allowing you to “see”/feel how information is clustered. As menus are typically in the same location, pushing for instance on the location could then allow you to focus your screen reader there, or push on the section that is centered and you could feel how much text is there; having different thicknesses or patterns of pins or groups could possibly indicate font-size for instance.

Maybe an idea to improve an already apparently very successful combination?

Tuukka Ojala says:

Having such a display would be nothing short of revolutionary. That would make it possible for me to do more front-end work, since right now the only way I can see how the elements are positioned is to use an iPad or other touch screen device, and it doesn’t really work that well for this kind of a job. Not only that, but having a tactile view of the desktop would make working with most programs a lot faster since I could just explore the window without having to use a keyboard for everything.

The Hyperflat is something like that: http://web.metec-ag.de/hyperflat.html
It has 76×48 dots.

Tuukka Ojala says:

I’d love to try this or some other similar device. I wonder if this one ever makes it to production. From what I could see it’s not being made yet.

Hello,

thank you very much for your writing about coding as a blind person. I have
been coding in Fortran for many years with a blind person (Jaws was his
screen reader together with a braille line). He sadly retired so I cannot
ask him the question I have.

What is the accessibility of a web component in Qt? That is, if I load a
webpage into a Qt web renderer, can your braille reader pick up the content
of the webpage correctly or not at all? Of course the webpage must be made
accessible, but this is something I know how to do it well.

My question is because on the Qt website, the only information about it is:
“The basics are in :-)”.
https://bugreports.qt.io/browse/QTBUG-40075

Tuukka Ojala says:

Sadly, that information is just about all there is to know. I haven’t tried the very latest releases of QT but so far the web renderer component has been inaccessible at least on Windows. However, the accessibility of QT apps differs from operating system to operating system, and it’s noticeably better on Linux, though I don’t know whether the web renderer component works there.

Sergey says:

You said that “Windows is the most accessible operating system there is.”. But actually it is not so. There are operating system designed specially for blind people. It is luwrain ( http://luwrain.org/index.php?lang=en&mode=normal ). It is very strange that you didn’t know about it.

Tuukka Ojala says:

No, I haven’t heard of this operating system. Maybe it isn’t used much outside Russian-speaking countries. However, there isn’t that much information on what it does, but from what little I could gather it looks like it’s much too restricted for my needs.

Yaele says:

Thanks for sharing,
What browser do you use – desktop/mobile?
Is there any way to overcome inaccessible website?

Tuukka Ojala says:

I’m using Firefox on the desktop and Safari on mobile. Chrome might eventually replace Firefox as my primary browser if they can get a few accessibility bugs ironed out.

As for overcoming inaccessible websites, it really depends on the particular problem. There are a million different pitfalls. The most extreme solution would be to write a Greasemonkey script to either enhance the accessibility of a website or make it usable at all.

Benjamin says:

Really nice post ! Looking forward to read your post about accessibility, so I could use that in my own developments 🙂

Hannan Ali says:

Did you go to college or are you a self taught programmer? What courses did you take there? Thanks for writing this post too 🙂

Tuukka Ojala says:

I graduated from Tampere university of Applied Sciences. I specialized in software development but we didn’t really have that much alternative courses to pick from. After specializing to one of the available subjects most people just went through the same curriculum.

isaac32767 says:

It’s interesting that, despite your preference for the command line, you don’t talk about command line editors. When I first got into Unix, that was all there was. I once knew an old Bell Labs hand who could edit in ed, the editor that originally came with Unix, as quickly as I could edit in vi. Note that vi started out as the visual mode of the ex editor, which was an expansion of ed.

The ex command line still exists within the vi editor, but I guess it doesn’t have the user ecosystem a serious programmer needs.

Tuukka Ojala says:

I did talk about them, actually, unless you meant specifically line editors like Ed. I haven’t tried them extensively, but I doubt those would give me much of a productivity boost especially now that I’m primarily working on a Java project.

Andy Berdan says:

I’m one of the original authors of the Speakup Project — http://www.linux-speakup.org/speakup.html

About 20 years ago, I had a job with the University of Western Ontario (now Western University) where I worked with Kirk Reiser, a fully blind sysadmin and developer who was very dissatisfied with his current workflow, which involved booting, loading emacs, and then a special major-mode that talked directly to the synth device. If anything failed during that sequence, he’d have to get someone sighted to help, and frequently had to resort to someone non-technical reading the reams of boot text. Frustrating indeed.

Over the next couple of years, he and I built a blind-specific console driver and maybe 10 or so hardware synth drivers, and a kernel-level screen reader control (based on DoubleTalk’s control model) to get the linux kernel talking directly to the synth as early as possible in the boot sequence. I think we missed the boot loader line, and maybe two lines of text before our console driver. It was a great accomplishment, and I love that I built something that really made people’s lives better.

Thanks for that trip down memory lane.

Tuukka Ojala says:

Wow, thanks for sharing! What a great story. Speakup is still being used actively. I use it with a software synthesizer whenever I’m working on a Linux machine.

Ben Burns says:

Thank you for sharing.

Dan Miner says:

I’m a visually impaired programmer and I’m losing my vision to the point that I had to switch to a screen reader nearly full time. I find it interesting to hear another’s viewpoint and especially what tools work. I am definitely puzzled by IntelliJ as I tried it and it failed horribly (ZoomText Fusion). However, I have switch to NVDA in last couple of months and maybe I should try it again.

I also use Linux, GNOME and Orca at home as I truly hate Windows. But I do have to agree there are more silent apps in that world (due to Tk and script bindings being inaccessible). There is hints of mono have accessibility but it is broken in Ubuntu. I’m really happy Qt 5 has improved accessibility a great deal.. Now if I could just figure out how to actually improve3 Orca and add accessibility to Tk… And then there is all the broken webkit based accessibility.. *sigh*

Tuukka Ojala says:

Did you have the Java Access Bridge enabled? IDEA doesn’t work at all without it. And yeah, I totally hear you there about all the accessibility issues. I have enough on my plate as it is without having to fight with software that could have been made to work but didn’t, so I’m sticking what works best for me and experimenting with new things only when I have some extra time to spare.

I would be very interested in seeing a video of you working. A video of your typing, reading code on your braille display, and a screen capture of your windows environment. 🙂

Great post! Question for you: when reading or writing code, which indentation style do you find to be more accessible- tabs or spaces?

Tuukka Ojala says:

Personally I prefer spaces but I’d say both of them are just as accessible. Tabs might theoretically be easier to work with since they show up as one character instead of n amount of whitespace. However, that makes them not show up as nicely in braille. I’d say there’s no reason to pick either one because of accessibility concerns.

Mikołaj Hołysz says:

1. I’m completely blind since birth and I mean completely, I can’t even see light, no matter how bright it is.
2. I have similar experiences and workflow as the author of this post, it’s mostly windows, notepad++, NVDA and firefox with occasional linux vms or linux via ssh and scp if I really need to. I hate Mac OS with a passion because of it’s completely broken speech synthesis API. That means that if I were to use Mac OS, I would need to either switch completely to english which is just not possible in my situation or use a human-sounding speech synth, more like the one you can hear in modern voice assistants, not like the one shown in that post.
I generally consider those synths annoying for daily work, I can stand using them on my Iphone or for tasks like reading non-technical literature but nothing more than that. They, in general, are harder to understand at faster speeds, are sometimes less responsive and decrease privacy because it’s easier for other people to understand them and overhear what I’m doing.
I really want to use linux more because there are some nead tools for it, particularly if I were to work almost completely in a terminal environment but sadly linux is not compatible with my hardware so I can’t really say how pleasant it would be to work that way.
I know it’s doable, I know people who do it, I know it has way more quirks than Windows does but it has some good tools too, like a set of scripts that makes emacs way more accessible than anything else we have.
I agree with the author on indentation and stuff he mentions, though I use some little tricks to compensate for the need to use speech instead of braille, I don’t have a big enough display to really make use of and my speed of reading braille is rather low comparet to an average blind person. For some context, the braille vs speech debate in the blind community is kind of like emacs vs vim in the development community. There’s no right solution for everyone and different people have different workflows, some relying completely on speech, some using braille as a secondary way of getting information, useful only in certain situations, but some use it and prefer it over speech, though usually they use speech too, maybe not as much but there are situations when it’s just more convenient.
So back to the subject, one thing I use extensively for coding is a feature of my screen-reader that announces indentation via playing tones, so if I’m reading some code and then down arrow to a line with more indentation, I can hear a tone and when the indentation changes again, the tone changes too. The pitch of that tone is dependent on how many spaces or tabs are there so it only makes sense when I remember the tone for the previous block, but I generally don’t have problems with that.
I mostly use it for verifying that I haven’t made any mistakes when indenting, because I don’t really use python that much and the languages I use have explicit block delimiters.
One thing I really like are automatic formatting tools like gofmt. For those of you who haven’t heard of it, gofmt is basically an utility that when run in a go package reformats all it’s files with go’s formatting conventions. This allows me to write code without any indentation at all and then use the tool to make it pretty. That way I’m sure that there aren’t any style-related mistakes because the tool just won’t make them.
Speaking about navigating big codebases and big files, one thing I use a lot when working with visual studio is the window under ctrl+f2, it allows me to jump quickly to a part of a file, so when I edit a file that’s for example 2000 LOC and it contains one class with 20 methods and I know specifically what method I’m interested in, that window lets me select it with my arrow keys, press enter and jump directly to it’s definition.
The fact that I’m not able to scan through the screen quickly and that scrolling with arrow keys generally takes more time than with the mouse, that thing makes my life much easier.
For things the author didn’t encounter or mention, one thing I don’t like are code conventions that have strange indentation rules, like when making an object / dictionary / associative array that spans multiple lines, the subsequent lines aren’t indented one level deeper but they’re indented so that all the fields align with eachother.
To show it more clearly, we can hase something like:
obj = { foo: “Bar”,
test: “test1”}
And that’s fine, but we can also have.
obj = { foo: “Bar”,
test: “test1”}
I hope I’ve written it correctly. Basically what I mean is that the t in test should be directly under the f in foo which is really hard but possible to do nonvisually.
Another thing that most blind coders struggle with are tools used in development but not directly related to it like slack, gitter, trello etc.
I haven’t really noticed it that much until recently because the things I worked were small projects that didn’t require collaboration but that recently changed.
so for example I made a couple of pull requests to a node.js text based game (MUD) called ranvier and they used a slack channel. Fortunately the developer was kind enough to turn on the IRC gateway for me which made things way easier. Slack web is usable though not pleasant to work and I have to use either the IRC gateway or the IOS app.
This is not that simple for other apps though. I have a friend who works with computers (he’s not a developer but similar stories happen to blind devs too). His company recently changed their security policies and now requires remote employees to use some kind of custom VPN solution which was not accessible. He somehow resolved the issue (I don’t know how, I suspect they allowed him to connect to it with something like openvpn) but for companies that have more strict policies or are less friendly this can be a serious problem making such a person completely unable to access their internal servers for some amount of time which might be catastrophic for a project with a tight deadline, especially if those decisions were made in a completely different department and making an exception is hard and takes time.

Someone asked how the author managed to use speech synths at such a rate, for me it started with human synths, when I got accustomed to them I discovered robotic synths which are way more responsive. This mattered a lot to me at that time because my computer wasn’t a really good one and human synths had like 1 second of lag. This might not seem much, but try editing a document with some editor over ssh with ping > 1000 ms and you surely will understand why that’s a problem.
So when I switched to a robotic synth called espeak which is the thing I still use, I started to gradually increase the speed and after a few months of really heave usage, I was able to use it at maximum speeds comfortably.
If you wonder how espeak sounds like, it’s exactly the same synth as the one shown in the english demo in this post, though I usually use it’s polish version.

To the one who asked about typing, most blind people learn to type quickly on a normal querty keyboard which is way easier than most people imagine. Braille keyboards, usually integrated into braille displays, are used too though they’re not an ideal solution for software development, they’re much better for ordinary text input.
To the one asking about web forums, it depends, usually it’s doable especially after you learn how that particular website works, how it’s structured and what shortcuts to use to get quickly to the parts you need the most. Try contacting me via twitter, @miki123211, direct messages open, if you want me to help with some particular website.
FOr the one askind about ex/ed, they’re usable but constantly rewriting the whole line is not pleasant. I generally prefer a basic editor that allows me to navigate and edit, even though I need to do it with arrow keys instead of the mouse. It’s just faster,
For anyone who wants to contact me, @miki123211 on twitter, gmail and almost everywhere else.

Daniel says:

Just in case you hadn’t heard of it yet, there’s now the Windows Subsystem for Linux: that might replace your Git Bash. I’d rather welcome you to Gnome Shell full time, but when I tried using Orca as a sighted person, I couldn’t hack it. (I was trying it because somebody complained about my shell extension not being screen reader accessible. It is now)

Tuukka Ojala says:

I’m actually using WSL for a couple of things, namely running Ansible on Windows. I guess I just can’t be bothered moving all my tweaks over from Git Bash to WSL since Git BAsh can deal with my day-to-day tasks just fine.

KeithF. says:

Outstanding post! Now, I have a new goal for my reader speaking rate. It is interesting that you use IntelliJ which I find almost totally inaccessible (on the Mac though) and use Eclipse instead. Keep up the good posts!

Tuukka Ojala says:

IntelliJ works almost as well as Eclipse on Windows. Strange that it doesn’t on Mac. As far as I know both require the Java Access Bridge to work.

Great article, Tuukka! Eclipse does not require the Java Access Bridge. It communicates directly with the platform’s accessibility API.

Tuukka Ojala says:

I stand corrected. Thanks for letting me know.

Johannes Löthberg says:

Have you ever tried ex/ed? They might work better with a brail display since they are line-editors meant for teletypes rather than video displays.

Tuukka Ojala says:

I keep meaning to but no, haven’t yet. I’ll go and have a try at some point, though I think it might be too limited.

Why are there pictures stuck to your cubicle wall?

Tuukka Ojala says:

Now, that is a good question which might actually be worth its own blog post (though not necessarily by me). I’ll get back to this.

Tuukka Ojala says:

I had this same question come to me on Reddit. One of my colleagues explained the concept like this:

“They are “not bad” diplomas with this picture: http://static-sls.smf.aws.sanomacloud.net/menaiset.fi/s3fs-public/styles/medium_main_image/public/main_media/1354098490_li_sisu_jorma2_panupalvia1.jpg?itok=h4bXAPb2
Our company gives them out when people give their coworkers praise for something on a specific Slack channel. The man pictured is a Finnish dancer and celebrity called Jorma Uotinen. “Not bad” is one of his catchphrases.”

Those pictures are the diplomas I’ve got. They do have some text in them as well but it might not be visible in the picture.

vranki says:

Interesting post. Is reading web forums difficult for you? I’m the author of Siilihai web forum reader and I’ve been planning to add braille/screen reader support for it for long time. It would be quite easy to implement some kind of non-visual user interface to it. But I have no clue what would be the optimal way to do that from user’s perspective.

Tuukka Ojala says:

The best you can do is identify what doesn’t currently work and then fix those bugs in your normal UI. It’s likely that your app works for the most part but has only some gotchas. Creating a separate non-visual UI is only asking for trouble and more maintenance effort on your part. Web forums are usually very straight-forward web pages and, while they could often be more optimized, they usually work well enough.

Your reading speed is impressive! What is typing like for you? Do you ever type in braille too? Do you have any 1337 keyboard hacks that really help? I’m super interested; speed helps us all!

Tuukka Ojala says:

I do type in braille on my phone. It’s much more efficient than finding your way around a miniature touch screen qwerty keyboard. As for keyboard tips:
1. Learn to touch-type if you haven’t already.
2. Memorize all the keyboard shortcuts to your most commonly used features in your editor/browser/whatever.

javipas says:

Fantastic. Congratulations for the post, for accomplishing this (showing there are little barriers if you really want to surpass them) and, of course, for your impressive hearing. Even reading the text while hearing it (I’m Spanish, but fluent in English) it’s almost impossible for me to follow what the screen reader is actually reading.

Thanks for writing this up. As a sighted Linux user I never had any notion of how good or bad the screen reader is / was; but it seems there is some overlap in preferences on code reviews (I find it impossible to give meaningful feedback if looking at split view, and as tests should say “here’s what was broken, here’s us fixing it I’m not required for most of that.

Are there any of your colleagues that are really good with producing accessible SW, and what if anything would you say is the difference between those colleagues and those that seem less interested or capable?

Tuukka Ojala says:

I think any of my colleagues (or in general, really) would be good at producing accessible software. Unfortunately most of them can’t because of time constraints. Accessibility on the web is something you have to dive into to get right. However, a couple of my colleagues took the time to wrap their heads around the core concepts of web accessibility and they have made some exceptional results.

calvin says:

I hear Visual Studio is quite accessible. I’ve seen how blind MS devs work with it and they’re pretty fast; they can even use the debugger pretty extensively.

Tuukka Ojala says:

Yes, they seem to be making progress in fixing its accessibility issues, including but not limited to the debugger. Might have to give it a try at some point although I don’t really get to work with .net languages all that much.

Steven Clarke says:

Visual Studio Code would be worth a look too (full disclosure – I am on the VS Code team at Microsoft). It’s a cross platform editor with support for JavaScript, HTML, CSS, node etc out of the box and many other languages through language service extensions.

We have done a lot of work to support screen readers and it would be great to hear your feedback if you do try it out.

Tuukka Ojala says:

Yes, imo Visual Studio Code is the most promising new editor out there. I installed it on all my machines a couple of weeks ago to see if it would be mature enough to replace Notepad++ for my use and it’s well on its way to do so. You’ve done an amazing job given what you had to work with.

Really well written article! Also, I find it REALLY impressive that you can read websites ‘linearly’ at such speed, and code with braille.

It is a shame that accessibility is usually not in mind for coding tools! If Vim was more friendly with your screen reader, I personally think it might work well since it does not rely too much on visual feedback anyway (not even in visual mode).

Tuukka Ojala says:

The problem isn’t actually in Vim, it’s console support in NVDA that needs some attention to work well with editors. However, there are more pressing issues affecting the ‘mainstream users’ that prevent this from being worked on.

Forgive me if I’ve misunderstood, but the audio samples you give, is that the actual speed you read/listen at? I find it very difficult to understand at that speed. How do you deal with language at such a rate? Did you start out slow and just get faster and faster?

Dennis says:

To me the speech samples sound like gibberish, even the one that you yourself recorded from your own voice: I would describe the sound as a very fast, metallic staccato of just broken pieces of words, with multiple audio streams overlaid over each other. To me it is just 22 seconds of unintelligible noise. Very similar to “morse code”, as you described it accurately. Are you actually able to speak like that or is sound playback for this website broken on my system?

maeghith says:

@Dennis, Unless I’m missing something, In this article there are two audio samples, none of them are from the author’s own voice, both are from speech synthesisers.

@Tuukka, thanks to enlighten (heh) us with this article, it’s been a great read.

Tuukka Ojala says:

Correct. Despite being subjected to it every day I don’t speak quite that fast.

Dennis says:

Thanks for clarifying that. I misread “Here’s a sample of this paragraph being read as I would read it:” to mean you actually read it, i.e. that “I” was referring to you, Tuukka. So the difference between the samples is that one uses the “robotic” voice you usually listen to, and the other uses a more natural voice, but both are spoken by synthesizers and both are at the same speed setting?

In any case: Thanks for the great article and a very interesting and helpful insight into the life of a fellow coder! 🙂

kelahcim says:

Samuel, just recall your colleagues telling you not to scroll that fast through the code, because they can’t follow what’s happening on the screen 😉

Tuukka Ojala says:

Yep. I started out using a regular speaking rate and increasing it over the years. You can’t just jump right in at that speed.

Mikael says:

Molly Burke has an excellent explanation video telling why voice speed is so fast:

https://youtu.be/7OEZX5lsQG8?t=10m17s

Basically just “because I’m used to it”.

Allan Vaughn says:

Speech to text is very much like Morse code in the speed aspect. Of course you’d have to start slow to learn it, then can speed up with time and practice.

Eddy Young says:

I enjoyed reading this post a lot. It made me realise how much more able a blind person must be in order to do software development. In my mind, you are probably a better developer than many fully-abled people because you need to be capable of retaining larger code structures in memory whereas we have the luxury of browsing text easily, and how you change code must be well-thought of in order to minimise errors. And, so on. Many of my pre-conceived ideas of how this works for you are probably still very wrong, but this post certainly shed some light on an aspect of software development that I had given little thought to until now.

Tuukka Ojala says:

You are probably right about that. But then, there’s a good chance my memory wouldn’t be as developed if I was sighted. This is one of those ‘what-ifs’ you really don’t want to get stuck to. Life is how it is and all you can do is just deal with it the best you can.

Join the conversation