Addressing Accessibility Barriers in Programming for People with Visual Impairments: A Literature Review
Aboubakar Mountapmbeme, Obianuju Okafor, Stephanie Ludi · 2022 · ACM Transactions on Accessible Computing · doi:10.1145/3507469
Summary
This systematic literature review analyzes 70 papers published between 2000-2020 examining accessibility barriers in programming for people with visual impairments and proposed solutions. The review covers both professional programmers and students learning to code, spanning text-based programming, block-based programming (like Scratch and Blockly), and tangible programming approaches. The authors identify five main categories of accessibility barriers: Code Navigation (difficulty finding information in codebases without losing cursor position), Code Comprehension (understanding program structure and logic), Code Editing (modifying code while maintaining context), Code Debugging (using visual debugging tools), and Code Skimming (getting quick overviews of code structure). The root cause of most barriers is the line-by-line sequential nature of screen readers, which fundamentally conflicts with the spatial, hierarchical structure of code. Blind programmers report using workarounds like temporary text buffers to store variable names, keyword search instead of visual scanning, and "print-f" debugging instead of inaccessible visual debuggers. The research methodology included database searches across ACM DL, IEEE, and Wiley, supplemented by manual venue searches and backward snowballing. Papers were thematically analyzed using axial coding, resulting in four main categories: programming paradigm, programming tasks and challenges, assistive technology, and interaction mechanism.
Key findings
Solutions identified in the literature fall into three categories. First, accessibility plugins and standalone tools enhance existing IDEs like Eclipse, Visual Studio, and NetBeans. Notable examples include StructJumper (creates hierarchical AST-based tree structure for Java navigation), CodeTalk (provides audio cues for syntax errors and accessible debugging with "talkpoints"), AudioHighlight (uses HTML heading tags to create hierarchical code structure), and Tactile Code Skimmer (physical device with sliders representing indentation levels). These tools primarily address code navigation and skimming challenges. Second, novel accessible programming languages have been developed from the ground up. Quorum is the most successful—an evidence-based language now used in K-12 curricula and universities globally, with an accessible IDE supporting keyboard navigation, screen readers, and magnification. APL (Audio Programming Language) relies solely on audio for input/output. GUIDL allows blind programmers to create GUI applications using natural language descriptions. Pseudospatial Blocks provides non-visual access to block-based programming through keyboard commands and text-to-speech. Third, accessible programming toolkits use tangible objects and audio output for teaching programming to children with visual impairments. Examples include Blocks4All (accessible iPad blocks programming), StoryBlocks and TIP-Toy (physical blocks creating audio stories), Torino (commercially available as Code Jumper, uses electronic beads), and various robotics toolkits like JBrick, Robbie, and TACTOPI. These tangible approaches provide tactile feedback that screen readers cannot offer.
Relevance
This review provides essential guidance for anyone developing or evaluating programming tools for accessibility. The identified barrier taxonomy (navigation, comprehension, editing, debugging, skimming) gives practitioners a framework for assessing IDE accessibility and prioritizing improvements. Several critical gaps emerge for future research. Code comprehension, editing, and debugging remain understudied—most research has focused on navigation challenges. Block-based programming accessibility research is still nascent despite the dominance of these environments in K-12 education (Scratch, Blockly). Most studies are experimental evaluations rather than longitudinal assessments of real-world adoption—a survey found only 4 of 15 blind programmers used tools specifically designed for them, suggesting awareness and dissemination problems. For practitioners, the review highlights that retrofitting accessibility onto visual tools is harder than building accessibility in from the start. The success of purpose-built solutions like Quorum and Blocks4All versus the limited adoption of plugins suggests organizations should consider accessibility as a foundational design requirement. The prevalence of tangible programming for education underscores that screen reader compatibility alone is insufficient—multimodal approaches combining audio, tactile, and keyboard interaction better match how blind users work.
Tags: visual impairment · blindness · programming · IDE accessibility · screen readers · code navigation · block-based programming · tangible programming · computer science education · literature review
Standards referenced: WAI-ARIA