[Paper] An Extension-Based Accessibility Framework for Making Blockly Accessible to Blind and Low-Vision Users

Source: arXiv - 2601.10688v1

Overview

Block‑based programming environments (BBPEs) like Scratch and Code.org have become the de‑facto way to teach coding to K‑12 students. However, their visual‑centric interfaces leave blind and low‑vision (BVI) learners largely out. The paper introduces an Extension‑based Accessibility Framework (EAF) that plugs into existing Blockly‑based editors without rewriting the core library, delivering a richer, screen‑reader‑friendly experience.

Key Contributions

• Modular extension architecture that can be dropped into any Blockly‑based BBPE, avoiding invasive code changes.
• 3‑D hierarchical navigation model with stack labeling and block numbering, giving BVI users a clear sense of program structure.
• Mode‑based editing controls that separate navigation from mutation, preventing accidental block moves or deletions.
• WAI‑ARIA integration to expose Blockly’s DOM to mainstream screen readers (VoiceOver, JAWS, NVDA).
• Empirical validation across two real BBPEs (177 test cases) and semi‑structured interviews with four BVI participants, showing measurable usability gains.

Methodology

1. Framework Design – The authors built EAF as a set of independent JavaScript extensions that wrap around Blockly’s existing APIs.
2. Navigation Model – They introduced a three‑dimensional traversal scheme:
   • Depth (entering/exiting nested stacks),
   • Breadth (moving left/right among sibling blocks), and
   • Layer (switching between “navigation” and “edit” modes).
     Stack labels (e.g., “If‑else block 2”) and sequential numbers are announced via ARIA live regions.
3. Implementation – WAI‑ARIA roles/attributes were added to Blockly’s DOM nodes, enabling screen readers to treat blocks as list items with hierarchical relationships.
4. Evaluation –
   • Technical coverage: Integrated EAF into two popular BBPEs and exercised 177 functional test cases (keyboard navigation, block creation, deletion, and rearrangement).
   • User study: Conducted semi‑structured interviews with four BVI participants using three screen readers. Participants performed typical programming tasks while thinking aloud, and their feedback was recorded and coded.

Results & Findings

• Spatial orientation: All participants reported a clearer mental map of nested blocks, attributing this to the stack‑labeling and numbering scheme.
• Error reduction: Mode‑based editing cut accidental block deletions by ~70% compared with vanilla Blockly keyboard navigation.
• Screen‑reader compatibility: WAI‑ARIA annotations allowed VoiceOver, JAWS, and NVDA to correctly announce block hierarchy and focus changes, something the default Blockly implementation fails to do.
• Coverage: The framework handled 100% of the 177 test cases, demonstrating that the modular extensions can replace the native navigation logic without breaking existing functionality.

Practical Implications

• For BBPE developers: EAF can be adopted as a plug‑in, dramatically improving accessibility without a full rewrite of the editor. This lowers the barrier for educational platforms to meet legal accessibility standards (e.g., WCAG 2.1).
• For educators & schools: Deploying an accessible BBPE means BVI students can participate in mainstream coding curricula, fostering inclusive STEM pipelines.
• For assistive‑technology vendors: The ARIA‑based approach provides a blueprint for exposing other visual‑heavy web tools (e.g., diagram editors, visual data‑flow languages) to screen readers.
• Open‑source community: Because EAF is built on top of the widely used Blockly library, contributions can be shared across projects, accelerating the ecosystem’s overall accessibility maturity.

Limitations & Future Work

• Small user sample: The qualitative study involved only four participants, limiting statistical generalization.
• Screen‑reader variance: While the three major screen readers were tested, differences in platform‑specific behavior (e.g., iOS vs. Android) were not exhaustively explored.
• Scalability of labeling: For very large programs, stack numbers can become unwieldy; future work could investigate dynamic summarization or hierarchical collapsing.
• Extension to non‑Blockly BBPEs: The current design assumes a Blockly foundation; adapting the concepts to other visual programming frameworks (e.g., Snap!, App Inventor) remains an open challenge.

---

Bottom line: The Extension‑based Accessibility Framework shows that a well‑engineered, modular plug‑in can turn a visual‑only programming environment into a genuinely inclusive learning tool—opening the door for blind and low‑vision students to code alongside their sighted peers.

Authors

• Rubel Hassan Mollik
• Vamsi Krishna Kosuri
• Hans Djalali
• Stephanie Ludi
• Aboubakar Mountapmbeme

Paper Information

• arXiv ID: 2601.10688v1
• Categories: cs.HC, cs.SE
• Published: January 15, 2026
• PDF: Download PDF