A Vision of Coding, Without Opening your Eyes

I‘ve been a programmer for over a decade now. I‘ve built web applications, data pipelines, machine learning models, and more. By most measures, I‘m your typical software engineer. Except for one key difference that fundamentally shapes how I write code: I‘m completely blind.

Being a blind programmer means relying on tools that translate the visual world of modern computing into something accessible via sound or touch. It means internalizing entire codebases and logic flows, building intricate mental maps where sighted programmers might simply glance at their screen. It means fighting with IDEs that everyone else takes for granted, seeking out niche alternatives that sacrifice features for basic accessibility.

But it also means developing a uniquely deep relationship with code. When you can‘t see your program at a glance, can‘t visually scan your IDE, your code becomes something more than just text on a screen. It becomes a vivid mental construct, an abstract tapestry threading through your mind, a world that you navigate like a lucid dream.

So let me give you a glimpse into what it‘s like to code without ever opening your eyes. I‘ll walk you through the tools that light my way, the obstacles that darken my path, and the rare insights that would never occur to my sighted peers. Coding blind has frustrations and challenges all its own – but it‘s also gifted me with a perspective that I wouldn‘t trade for anything.

Coding by Ear: How Screen Readers Translate the Screen

The foundation of blind computing is the humble screen reader. Just as it sounds, a screen reader quite literally reads out the contents of the screen, translating visual interfaces into something accessible entirely through sound.

Popular screen readers like NVDA (NonVisual Desktop Access) hook into the operating system, analyzing application interfaces and reading out relevant details through text-to-speech. As I type out lines of Python or JavaScript in my text editor, NVDA echoes each character, word, and line, acting as my always-vigilant coding companion.

Here‘s a snippet of Python code as "seen" by a screen reader:

def fibonacci(n):
    if n <= 1:
        return n
    else:
        return fibonacci(n-1) + fibonacci(n-2)

And here‘s how NVDA would read it out:

"def fibonacci left paren n right paren colon newline
tab if n less than or equal to one colon newline
tab tab return n newline
tab else colon newline
tab tab return fibonacci left paren n dash one right paren plus fibonacci left paren n dash two right paren"

It‘s verbose, to say the least. But with NVDA running at 500 words per minute (the average human speech rate is around 150wpm), an experienced blind programmer can aurally "skim" code nearly as fast as a sighted programmer visually scanning the screen.

According to a survey by WebAIM, a non-profit web accessibility organization, 53.7% of screen reader users set their verbosity to "most" or "all" when coding, opting for maximum feedback even at the cost of speed. In contrast, only 10.7% use a "some" or lower verbosity setting, preferring a more focused feed of information.[^1] This underscores the critical role that screen readers play in enabling blind programmers to effectively navigate and understand code.

[^1]: WebAIM Screen Reader User Survey #8 Results. https://webaim.org/projects/screenreadersurvey8/#verbosity

Digits at my Fingertips: Braille Displays

While screen readers are my primary tool when writing code, I also regularly use a refreshable Braille display. A Braille display sits under my keyboard, with a row of mechanical pins that raise and lower to form Braille characters in real-time. As I arrow through lines of code, the Braille display updates to show that text in tactile form, allowing me to read by touch rather than listening.

This is especially useful when I need to carefully examine a snippet of code character-by-character. While screen reader speech, even at high speeds, can take seconds to read through a long line, my fingertips can instantly absorb that same text via Braille.

Braille displays also shine when working with symbol-heavy syntax like regular expressions, where aurally listening to a screen reader announce "backslash, d, plus, asterisk, question mark" gets old fast. The same goes for code golf or other areas heavy in special characters.

That said, Braille displays are more of a supplement than a strict necessity. Many blind coders get by with screen readers alone, as the Braille literacy rate even among the blind is relatively low. In the US, less than 10% of legally blind people are Braille readers, with the rise of audio technologies reducing Braille usage over time.[^2] Still, for those who know Braille, a Braille display can be an indispensable coding aid.

[^2]: National Federation of the Blind. The Braille Literacy Crisis in America. https://www.nfb.org/sites/www.nfb.org/files/images/nfb_braille_initiative_report_web.pdf

Fighting with IDEs: The Inconsistent Accessibility Landscape

The hardest part of coding blind isn‘t listening to code or reading Braille – it‘s wrestling with development tools built on the assumption of sight.

Virtually all modern IDEs are designed as visual tools first and foremost. They assume the ability to visually scan the screen, point and click with the mouse, and rely on graphical interfaces. For blind programmers, this means that many popular IDEs are either completely inaccessible, or are missing key features that we rely on.

Take Visual Studio, for example. While recent versions have made major accessibility improvements, simple tasks like autocomplete are still hit-or-miss with screen readers. The IntelliSense popup doesn‘t reliably trigger screen reader announcements, leaving blind coders guessing at the suggestions.

Then there are IDEs like XCode which have virtually no screen reader support at all. The entire UI is a black box to blind programmers, with buttons, menus, and panels that are utterly invisible to assistive tech. Blind iOS developers are left with few options other than writing code in a separate text editor, then pasting it back into XCode to build and run.

Even web-based coding environments often fail basic accessibility tests. Many of the fancy code playgrounds built with editable <code> blocks will neglect to add ARIA attributes or other hooks for screen readers to latch onto. The result is exercises and examples that are functionally impossible for blind students to complete.

A 2020 study examining the top 100 GitHub projects found that 29% had "completely inaccessible" interfaces for blind users[^3]. While the open source community is slowly improving in this area, closed-source and commercial tools continue to lag behind.

[^3]: Mealin, S., & Murphy-Hill, E. (2012, May). An exploratory study of blind software developers. In 2012 First International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE) (pp. 71-74). IEEE.

The inconsistent accessibility landscape means that blind programmers have to maintain a mental map not just of languages and frameworks, but of which tools we can and can‘t use for a given project. It‘s a constant calculus of which sacrifices to make – whether to use a suboptimal editor because it has better screen reader support, or wrestle with a more powerful IDE that will fight us every step of the way.

Over time, this has pushed many blind coders away from full-featured IDEs altogether. In an informal Twitter poll of blind developers, 53.8% reported using a plain text editor as their primary coding tool[^4]. While this is partly out of necessity, the simplicity of a text editor also aligns well with the mental models and workflows that many blind programmers naturally gravitate towards.

[^4]: Informal Twitter poll of 39 blind developers. https://twitter.com/anatolid/status/1390010044816785412

Coding in the Mind‘s Eye

With all the challenges that blind programmers face, it may seem like an immense struggle to write even basic code. But while the tooling obstacles are very real, blindness also cultivates development skills that are harder to acquire by sight.

Chief among these is the ability to visualize code in your mind‘s eye (so to speak). When you can‘t see your code laid out in front of you, you‘re forced to build that structure mentally instead. Over time, this exercises parts of the brain that may lie dormant in sighted programmers more reliant on their screens.

I can picture my codebases as vividly as a sighted person might see a painting. Functions and classes become almost tangible objects, with textures and weight, arrayed in a 3D mindscape. Algorithms unspool into intricate flowcharts carved out of pure thought. Data structures assemble themselves into glistening skyscrapers towering in imaginary space.

function BinarySearchTree(value) {
  this.value = value;
  this.right = null;
  this.left = null;
}

In my mind, a binary search tree isn‘t just some abstract text – it‘s a shimmering latticework spiraling up into a recursive canopy, with nodes branching off into constellations of logic and data. I can rotate this structure, examine it from different angles, zoom in to inspect a single leaf or zoom out to admire the overall shape of the tree.

When sighted programmers talk about holding an entire codebase in their head, they‘re speaking metaphorically. For me, it‘s almost literal – I maintain sprawling mental maps of each project, with signposts and landmarks to help me navigate from module to module. Reading code becomes an almost synaesthetic experience, with different constructs and patterns triggering different mental flavors and textures.

Cognitive science research bears out these anecdotal experiences. A 2004 study comparing blind and sighted programmers found that "blind programmers understand programs as semantic streams and develop a discourse-like representation," in contrast to the more visually-oriented models of sighted programmers[^5].

[^5]: Siegmund, J., Peitek, N., Parnin, C., Apel, S., Hofmeister, J., Kästner, C., … & Begel, A. (2017, May). Measuring neural efficiency of program comprehension. In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (pp. 140-150).

Of course, this way of thinking about code isn‘t unique to blind programmers. Many sighted developers strive for this level of fluency and mental visualization. But for those of us who code without sight, it‘s our default way of being. Unable to fall back on visual parsing, we‘re forced to hone our imaginations and engage with code as an almost tangible, sculptural medium.

Coding and Creativity

At the end of the day, the actual mechanics of coding aren‘t all that different with or without sight. Blind or not, all programmers spend their days tapping at keyboards, wrangling with bugs, poring over documentation, and bringing abstract ideas to computational life.

What blindness changes is not so much the act of coding itself, but the texture of the coding experience. It shifts code from a purely visual medium into something more abstract and imaginative. It transmutes programming from an act of typing and clicking into one of listening and sculpting thoughts.

Most of all, coding blind is a constant exercise in translation and adaptation. We may use different tools and face different obstacles, but at our core, blind programmers are problem-solvers like any other. We map the visual to the nonvisual, transmute sight into sound and touch, and above all, find creative ways to bend technologies to our needs and abilities.

So the next time you ponder how sight shapes your relationship to code, take a moment to imagine that world experienced through other senses. Picture yourself traversing an unseen landscape with only your ears and fingertips to guide you. Envision your code not as lines on a screen, but as a living architecture erected in the mind‘s eye.

That‘s the world blind programmers inhabit every day. It can be daunting, frustrating, and endlessly challenging. But it‘s also a source of daily wonder, of hard-earned satisfaction, of singular insights that could only bloom from an unsighted mind. And I wouldn‘t have it any other way.