ToPSen: Task-Oriented Priming and Sensory Alignment for Comparing Coding Strategies Between Sighted and Blind Programmers

TL;DR

This study introduces ToPSen, a design framework that reframes sensory constraints as technical requirements to compare coding strategies between sighted and blind programmers using audio feedback. By controlling perceptual channels and standardizing tasks on a headless server with text-to-speech feedback, the authors conduct a controlled study with 12 blind and 12 sighted participants across code reading, error correction, and code writing tasks. They find that expert blind programmers develop more robust mental models and manage cognitive load effectively, while ToPSen-trained sighted programmers approximate some blind strategies but incur higher extraneous load and miss structural cues. The work yields design implications for accessible IDEs and mixed-ability collaboration, including structured representations, cursor-tracking features, and potential AI-assisted tools, with a roadmap for applying ToPSen to other sensory modalities and future standardization efforts.

Abstract

This paper examines how the coding strategies of sighted and blind programmers differ when working with audio feedback alone. The goal is to identify challenges in mixed-ability collaboration, particularly when sighted programmers work with blind peers or teach programming to blind students. To overcome limitations of traditional blindness simulation studies, we proposed Task-Oriented Priming and Sensory Alignment (ToPSen), a design framework that reframes sensory constraints as technical requirements rather than as a disability. Through a study of 12 blind and 12 sighted participants coding non-visually, we found that expert blind programmers maintain more accurate mental models and process more information in working memory than sighted programmers using ToPSen. Our analysis revealed that blind and sighted programmers process structural information differently, exposing gaps in current IDE designs. These insights inform our guidelines for improving the accessibility of programming tools and fostering effective mixed-ability collaboration.

Figures (5)

• Figure 1: A screenshot of our simple, accessible IDE used in the study. It has two main components: the Editor (top) and Output panel (bottom). It provides TTS output that matches standard screen reader behavior, indicated by the red speaker icon.
• Figure 2: (a) The two anchor points to count the number of spaces. (b) - (d) Three different ways to reach anchor points.
• Figure 3: Five code snippets written by the participants and the associated errors, separated by a dashed line. In all error messages, the visual indicator indicates the location of the error. In the first two snippets, the only difference is the missing ')' at the last line, which changes the error message. In the second snippet, the statement with the error is also missing. In the last three snippets, the indentation of the else statement and the colon (:) are different, which changes the error message.
• Figure 4: A sequence of editing steps leading to a deviation from the mental model. The cursor at each editing step is represented using a red vertical line. (a) The participant writes the print statement and writes opening and closing brackets first to match the pair. (b) The participant moves left to place the cursor inside the brackets. (c) The participant types the argument of the print statement. (d) The participant presses Enter to move to the next line without checking the cursor location. The closing bracket moves to the next line without the participant having any clue. The TTS does not provide any cue to indicate this. (e) The participant continues writing the code, and the error continues to move away, deviating from the participant's mental model. As a result, the participant faces difficulty figuring out the issue when they encounter an error.
• Figure 5: Potential design to align sighted programmers' mental model with blind programmers during mixed-ability collaboration.