Interviews and Observation of Blind Software Developers at Work to Understand Code Navigation Challenges
Khaled Albusays, Stephanie Ludi, Matt Huenerfauth · 2017 · Proceedings of the 19th International ACM SIGACCESS Conference on Computers and Accessibility (ASSETS) · doi:10.1145/3132525.3132550
Summary
This exploratory study investigates code navigation challenges faced by 28 blind software developers using their preferred coding tools and assistive technologies. The researchers at Rochester Institute of Technology and University of North Texas conducted remote interview and observation sessions via Skype and Google Hangouts, where participants (all male, aged 22-52, with 5+ years programming experience, from five countries) demonstrated their coding workflows, navigation difficulties, and workaround strategies. The study builds on a prior survey of 69 blind programmers that identified code navigation as a key concern but lacked in-depth follow-up. Participants used diverse setups: all used screen readers (NVDA n=12, JAWS n=10, others), 8 used braille displays, and they worked across 14 programming languages (Python most popular at 64%) and 15+ editors. A critical finding was that all participants preferred simpler text editors (Notepad++, Notepad, Notepadqq) over full IDEs despite acknowledging IDEs' benefits — because IDEs' complex visual interfaces, pop-ups, and navigation features were largely inaccessible to screen readers. The study catalogued 14 distinct types of navigation difficulties, ranked by how many participants reported each.
Key findings
The most frequently reported navigation difficulties were: debugging (24 participants) — most debugging tools were inaccessible to screen readers, forcing developers to rely on printf/print statements; line-by-line navigation (23) — screen readers enforce linear traversal, making it time-consuming to locate specific code in large codebases; indentation (22) — screen readers verbalize each space character individually ("space, space, space, space" rather than "four spaces"), making Python and other indentation-based languages extremely challenging; nesting (20) — difficulty understanding deeply nested structures beyond three levels; backtracking (18) — inability to quickly return to a previous position after examining related code; and error location (14), scope understanding (14), character perception (10), and autocomplete inaccessibility (9). Participants employed extensive workarounds: writing custom screen reader scripts to calculate and verbalize whitespace counts; using braille displays to feel indentation levels (especially valuable for Python); placing code comments as navigational bookmarks (then removing them before sharing code with sighted colleagues, due to embarrassment); using keyboard shortcuts to jump through code structure; and seeking sighted help for quick codebase overviews (while most avoided this due to embarrassment about task completion time). When asked about desired features, 82% expressed interest in: tree view for hierarchical code navigation (64%), bookmarks/tags for code locations (86%), nesting and scope level indicators (68%), auditory feedback for code events (68%), and class relationship tools with audio cues (61%). Participants explicitly noted that "the way how programming relies on visual representation is the major impact in almost all difficulties that we face as blind individuals."
Relevance
This is one of the largest studies of blind programmers to date and provides essential empirical evidence for improving IDE accessibility — a topic with growing importance as software development becomes increasingly central to the economy. For accessibility practitioners, IDE developers, and employers, the key takeaways are stark: despite 50+ years of IDE development, these tools remain fundamentally designed around visual metaphors (color coding, spatial indentation, visual debugging, UML diagrams) that exclude blind developers. The finding that experienced blind programmers revert to simple text editors — sacrificing the productivity benefits of IDEs — because the tools are inaccessible represents a significant workplace equity issue. The social dimension is equally important: participants felt uncomfortable disclosing navigation difficulties to colleagues and avoided seeking help, potentially preventing them from advocating for better tools. The participants' specific feature requests (tree views, audio cues, bookmark systems, scope indicators) provide a concrete roadmap for IDE makers. The study's limitations include focusing only on experienced, fully blind developers — novice programmers and those with low vision may face different challenges.
Tags: blindness · programming education · software engineering · screen readers · workplace accessibility · code navigation · IDE accessibility · assistive technology