Assistive Technology Design as a Computer Science Learning Experience
Thomas B. McHugh, Cooper Barth · 2020 · Proceedings of the 22nd International ACM SIGACCESS Conference on Computers and Accessibility (ASSETS 2020) · doi:10.1145/3373625.3417081
Summary
This paper from Northwestern University addresses a persistent gap in computer science education: the near-complete absence of accessibility topics from non-HCI computer science courses. The authors first conducted a formative needfinding study with 16 undergraduate CS students that confirmed the problem — eleven of the sixteen students reported that accessibility is never discussed in non-HCI/Design CS courses, and accessibility topics were discussed 26.25% more frequently in HCI courses than in other CS courses (a statistically significant difference, p=0.0001). Only five students were familiar with standards like WCAG or WAI. The authors respond to this gap by presenting V11, a cross-platform JavaScript programming interface designed to make building assistive technology accessible to novice CS students. V11 abstracts the platform-specific accessibility APIs (macOS AXUIElement, Windows IUIAutomation, Linux ATK) into a unified DOM-like structure that feels familiar to students who have learned web programming. The library provides four core capabilities: listening for keyboard and application events, retrieving system information, querying and modifying an application's accessibility tree, and presenting information through audio and visual modalities. The design deliberately mirrors the JavaScript Document Object Model API, lowering the learning curve for students already familiar with web development concepts. To evaluate V11, the authors conducted 90-minute design workshops using a modified Google Design Sprint method with ten undergraduate CS students, who brainstormed and prototyped assistive technology solutions for a real accessibility challenge: making multi-track audio editing more accessible in GarageBand for visually impaired audio engineers.
Key findings
The workshop evaluation produced statistically significant results across multiple measures. Student interest in building accessible technology increased by 28% on average (from 2.7/5 to 4.1/5, p=0.0024), and V11 was rated 32% easier to learn than previously used accessibility programming tools (4.3/5 versus 2.7/5, p=0.0016). Workshop effectiveness for teaching accessibility was rated 4.6/5. During the brainstorming phase, participants generated an average of 4 designs each (42 total), which fell into three categories: information retrieval interfaces that query track state without the GUI, task automation interfaces that automate complex multi-step actions like applying effects or toggling mute across tracks, and command-line interfaces combining both approaches. Student reflections revealed that V11's DOM-like API design made it feel immediately familiar — one student noted it "felt very similar to the DOM model of online websites." Critically, students reported they would not have known where to start building assistive technology without V11, highlighting the barrier that platform-specific accessibility APIs pose to newcomers. Students also identified cross-curricular applications, noting V11 could fit into operating systems courses, web development courses, and dedicated accessibility courses. Areas for improvement included better error messages and more example code snippets.
Relevance
This paper makes a compelling case that accessibility education belongs throughout the CS curriculum, not just in HCI electives — a message directly relevant to anyone involved in training the next generation of developers. The finding that accessibility is essentially invisible in non-HCI CS courses helps explain why so many working developers treat accessibility as an afterthought rather than a core design concern. V11's approach of abstracting platform accessibility APIs into a familiar programming model offers a practical template for reducing the technical barriers that prevent instructors from incorporating accessibility into introductory courses. For accessibility practitioners and advocates working with educational institutions, the 28% increase in student interest demonstrates that hands-on experience building assistive technology is more effective at fostering accessibility awareness than teaching standards as abstract checklists. The paper also raises an important future direction: empowering non-programmers with disabilities to build their own solutions, moving beyond allyship toward self-advocacy through technology. The workshop methodology itself — using real accessibility challenges rather than hypothetical scenarios — provides a replicable model for accessibility education.
Tags: computer science education · assistive technology · inclusive design · accessibility pedagogy · allyship · programming tools · curriculum design
Standards referenced: WCAG 2.1 · WAI