Blocks4All Demonstration: a Blocks-Based Programming Environment for Blind Children
Lauren R. Milne, Catherine M. Baker, Richard E. Ladner · 2017 · Proceedings of the 19th International ACM SIGACCESS Conference on Computers and Accessibility (ASSETS) · doi:10.1145/3132525.3134774
Summary
Blocks4All is a tablet-based iOS application designed to make blocks-based programming accessible to blind and low-vision children. Blocks-based programming environments like Scratch and Blockly have become central to K-12 computer science education — of the 162 Hour of Code projects on Code.org designed for pre-readers through age 8, nearly half use blocks-based environments. These tools make programming approachable by letting children drag and drop code blocks that snap together like puzzle pieces, eliminating syntax errors and providing spatial cues about program structure. However, their heavy reliance on visual metaphors and drag-and-drop interactions makes them fundamentally inaccessible to screen reader users, effectively excluding blind children from much of the current computing curriculum. The researchers at the University of Washington developed Blocks4All following three core design principles: design for sighted, blind, and low-vision children simultaneously; build on mainstream technology already in use (specifically iOS with VoiceOver); and design specifically for children rather than adapting adult tools. The prototype supports the same feature set as ScratchJr, targeting ages 5-7, and can control a Dash robot through non-visual commands like movement and sounds. The application provides three different methods for adding blocks to a program: audio-guided drag-and-drop, selecting a block then a workspace location, and selecting a workspace location then choosing a block. To make program structure understandable without vision, blocks are uniformly sized and arranged in a single horizontal row, with two methods for indicating nesting: spatial bumping of nested blocks and begin/end repeat blocks paired with audio cues. The interface uses high contrast for low-vision users and works fully with VoiceOver.
Key findings
Early user studies with four blind and low-vision children informed several key design decisions. Uniformly sized blocks placed in a single row proved easier to find and navigate than the freeform spatial layouts used in visual environments. Multiple interaction methods for adding blocks (drag-and-drop, two forms of select-then-drop) give children options suited to their comfort level with touchscreen interactions. The research confirmed that young blind children are often more familiar with touchscreen-based screen readers (VoiceOver on iOS) than desktop screen readers, supporting the decision to build on tablet technology. The prototype preserves the three key advantages that make blocks-based programming effective for sighted children: elimination of syntax errors through block units, code creation through recognition-based menus rather than recall, and spatial hints about scope and nesting. Previous work on making blocks-based environments accessible had focused on desktop screen readers using hierarchical menus; Blocks4All's touchscreen approach offers spatial exploration as an alternative that may be more intuitive for young children.
Relevance
This work addresses a critical gap in accessible STEM education: as blocks-based programming becomes a standard part of K-12 curricula, blind children risk being left behind entirely. The demonstration highlights a broader principle relevant to accessibility practitioners — when educational tools are built around visual metaphors, making them accessible requires more than adding screen reader support; it demands rethinking the interaction model. Blocks4All's approach of providing multiple interaction methods (drag-and-drop, select-drop in both directions) is a practical example of designing for diverse user needs within a single application. The choice to build on mainstream iOS/VoiceOver rather than specialized hardware is strategically important: it means the tool can be used in mainstream classrooms alongside sighted peers. For developers building educational technology, the key takeaway is that accessibility must be considered from the design stage, not retrofitted, especially for tools targeting children who may not have the technical sophistication to work around barriers.
Tags: programming education · blindness · children · touchscreen accessibility · screen readers · blocks-based programming · educational technology · inclusive design