Accessible Blockly: An Accessible Block-Based Programming Library for People with Visual Impairments
Aboubakar Mountapmbeme, Obianuju Okafor, Stephanie Ludi · 2022 · Proceedings of the 24th International ACM SIGACCESS Conference on Computers and Accessibility (ASSETS) · doi:10.1145/3517428.3544806
Summary
This paper presents Accessible Blockly, a prototype library that augments Google's Blockly — the open-source library underlying most mainstream block-based programming environments (Scratch, MakeCode, AppInventor) — with keyboard and screen reader interaction capabilities. Block-based programming environments (BBPEs) let users code by snapping together visual blocks rather than typing syntax, making them popular for teaching coding to novices and widely used in K-12 education. However, their inherently visual and mouse-centric design makes them inaccessible to people with visual impairments, effectively excluding blind and low-vision students from programming activities where these tools are used. Accessible Blockly maintains the original visual interface while adding two key components: a Keyboard Module that enables WASD-key navigation through block programs with separate Navigate and Edit modes, and a Screen Reader Module that generates aria-label text descriptions of blocks at runtime. The design was guided by five principles: usability by both sighted and visually impaired users on the same platform (enabling collaboration), communication of visual information through speech and audio, keyboard interaction as a mouse alternative, easy integration into existing Blockly-based environments, and ease of learning. The Navigate mode allows spatial exploration of programs (up/down between blocks, left/right between connected blocks, into/out of container blocks), while Edit mode focuses on connection points for attaching new blocks. The library uses WAI-ARIA guidelines and has been tested with NVDA, VoiceOver, and JAWS screen readers.
Key findings
In a study with 12 blind programmers (10 blind, 2 with no useful vision; ages 22-60; using NVDA and JAWS), participants completed code navigation tasks using both Accessible Blockly and Blockly's existing alternate keyboard navigation as a control. Accessible Blockly produced significantly faster task completion — averaging 1 minute 30 seconds versus 2 minutes 55 seconds for the control (p=0.0035). Participants also scored higher on task accuracy with Accessible Blockly (avg. 3.17/4 vs. 2.75/4) and rated it easier to use (4.33/5 vs. 3.75/5). The key advantage was reduced cognitive load: Accessible Blockly's Navigate mode lets users move between blocks without having to process connection point information, which participants found overwhelming and disorienting in the alternate scheme. Nine of 12 participants explicitly found Accessible Blockly easier to navigate. An interesting split emerged by experience level: novice programmers strongly preferred Accessible Blockly for its simplicity, while experienced programmers saw value in the alternate scheme's more detailed connection point information for editing complex programs. Participants were notably enthusiastic — 9 of 12 displayed positive emotions, frequently smiled, and expressed strong interest in the accessibility of block-based programming. Participants suggested improvements including hints about container blocks, a quick review mode for whole-program summaries, and richer screen reader feedback about coding environment actions.
Relevance
This work addresses a critical equity issue in computer science education: as block-based programming becomes the default way to introduce coding in K-12 schools, blind and low-vision students are excluded from these foundational learning experiences. Teachers of students with visual impairments (TVIs) currently must find alternative tools that often support only basic concepts, putting their students at a disadvantage. Accessible Blockly's approach of augmenting the existing library rather than creating a separate system is strategically important — it means any Blockly-based environment could potentially become accessible, and sighted and blind students could collaborate on the same platform. For accessibility practitioners, the design insight about cognitive load is broadly applicable: when making visual interfaces accessible, reducing information overload (rather than simply exposing all visual details) can produce better outcomes. The distinction between navigation and editing modes mirrors how experienced screen reader users already separate reading and interaction in other contexts. The library is open source, making it available for integration into educational programming environments.
Tags: block-based programming · screen readers · keyboard navigation · blind programmers · computer science education · visual impairment · WAI-ARIA · coding accessibility
Standards referenced: WAI-ARIA 1.2