Software Engineering with a Screen Reader

As a blind software engineer, I do not scan a file visually. I move through it with a screen reader, listen to the code one line at a time, and use keyboard commands to move between the parts I need.

The tools are different, but the work is still software engineering: understand the requirements, read the existing code, make a change, test it, and review the result.

A screen reader such as NVDA, JAWS, or VoiceOver reads the text and controls in an application out loud. I use NVDA, and for code I change three settings first: I hear every symbol, I hear indentation, and I hear when a letter is a capital. Spoken indentation lets me follow a Python block, and hearing every symbol is how I catch a missing parenthesis or brace. I cover the exact steps in NVDA Settings for Coding.

Keyboard navigation is a large part of how I work. A few of the shortcuts I use every day:

• Ctrl+P in VS Code to open a file by name
• Ctrl+K then Ctrl+0 to fold a large file so I hear its structure first
• NVDA's H, K and T keys to move through headings, links and tables on web pages like GitHub
• Alt+F2 to open VS Code's Accessible View when a terminal has a lot of output to read

This is why good keyboard support matters in an editor. A feature that only works with a mouse is a feature I may not be able to use.

Accessibility varies by tool and by version. I use Windows, NVDA, Visual Studio Code, and WSL with Ubuntu because that combination works well for the way I develop. I walk through the whole setup in My Development Environment on Windows with a Screen Reader.

An accessible tool needs more than readable text. Controls need useful labels, keyboard focus needs to move in a predictable order, and important state changes need to be announced by the screen reader. The only reliable way to know whether a tool works for a specific developer is to test the actual workflow.

The same goes for AI. When I use it to write code, I still read every line with NVDA, which is why I wrap my coding agents in a harness of rules and checks.

Some blind developers also use a braille display to read code through touch. That can be useful for punctuation, spelling, and precise character-level review.

Clear code helps every developer, including developers using screen readers. Useful practices include:

• descriptive names
• consistent formatting
• small functions with one purpose
• useful command-line output
• documentation that does not depend only on screenshots
• tools and workflows that can be completed with the keyboard

Accessibility is not separate from engineering quality. When a codebase and its tools are clear, predictable, and testable, they are easier for the whole team to work with.