Systems for Scaling Accessibility Efforts in Large Computing Courses

AI summary

Overview

Research area: Computing education (cs.CY) with a focus on accessibility — specifically, making large university programming courses usable by disabled students. CCS categories listed by the authors are "Social and professional topics — Computing education" and "Human-centered computing — Accessibility."

Technical level: Intermediate. This is an experience report rather than an algorithmic or empirical-study paper, so there is no mathematics to follow, but it assumes familiarity with HTML semantics, screen readers, WCAG 2.1, PDF/LaTeX tooling, and CI/CD pipelines.

Scope (one sentence): The paper describes the auditing, remediation, technical, and human systems the authors built to make a three-course introductory programming sequence serving over 3500 students and more than 100 teaching assistants per year accessible at scale.

What This Paper Is About

Large computing courses face accessibility problems that are hard to fix because course content and course staff turn over constantly. The authors report on their attempts to audit and remediate accessibility issues in an introductory programming sequence at the University of Washington, then to move beyond reactive fixes by building proactive technical infrastructure and training-based human practices. Their goal is to share practical, adaptable approaches with other computing educators working at similar scale.

Key Contributions

1. Auditing and remediation systems. The first author audited assignments and materials in CSE 122 and CSE 123 (Spring 2025), classifying every issue across dimensions including platform, course element, format, reference location, context/purpose, issue description, instructional necessity, fix suggestion, and whether the fix is trivial. The team then developed content-type-specific remediation strategies for text, images/figures, video, and presentation materials.

2. Technical systems for proactive accessibility. Three approaches: replacing PDFs with web-first materials (Markdown compiled to HTML, math via MathJax), providing alternate accessible "views" for PDF-only content (slide source files, pandoc or tex4ht conversions of TeX-generated PDFs), and continuous automated accessibility testing with the Nu HTML Checker and axe-core in CI/CD pipelines.

3. Human systems for accessibility literacy. TA-targeted trainings built on hands-on activities ("Guess the Assignment," "Spot & Improve," "Should it alt text?," "Fix the Deck"), explicit course-wide accessibility norms for staff, and student-facing accessibility content and norms (including discouraging code screenshots).

4. An openly shared toolkit and lessons learned. Supporting materials, including audit templates and training activities, are published at the accompanying website, and the paper closes with challenges, limitations, and advice for others building similar systems.

Main Findings

• Audit volume was substantial. Across the two audited courses, CSE 122 had 21 lectures/PowerPoints, 16 recitation sections, 8 assignments, 83 unique resources, and 354 issues identified; CSE 123 had 20 lectures/PowerPoints, 16 recitation sections, 8 assignments, 103 unique resources, and 556 issues identified.
• Newer materials had fewer problems before remediation. A brand-new assignment had 22 fewer audited issues than the assignment it replaced, before any remediation took place, despite having a longer specification and otherwise similar diagrams and math.
• Automated browser tests caught many issues missed by validators. Using axe-core tests across several course and research group websites, the team caught and resolved over 1000 unique issues across over 300 pages, with no false positives. The issues most commonly missed by the validator but flagged by axe-core were low color contrast (especially with syntax highlighting), links without discernible text, page landmark issues, and improper use of tables.
• Web-first materials were adopted and well received. Reference sheets rewritten in Markdown, compiled to HTML, and published on the course website passed the audits and received significant positive feedback and widespread adoption; the approach was expanded to a course glossary, the final exam reference sheet (also distributed in print), and a seating chart.
• Video remediation was the hardest category. Most identified video issues were labeled "Non-Trivial Fixes," requiring substantial editing or a complete re-recording.
• TA engagement was strong and sustained. Feedback on the accessibility trainings was unanimously positive. After training, some TAs took on additional accessibility tasks in the course, engaged in broader campus initiatives, and continued the work in other classes they supported.
• Student engagement was positive. Students most often appreciated learning about assistive technologies and accessibility features when authoring content, for example adding alt text to images uploaded to social media, and reflected on how accessibility features help all users through improved legibility, clarity, or search.
• Accommodations were partially met by default. Many disability accommodation requests relating to course materials had already been addressed by these systems, substantially reducing the scope of necessary remediation, though additional work was still needed.
• Some issues got worse over time. A one-year longitudinal audit found an increase in reading and tab order issues within presentation slides, which the authors attribute to the lack of hands-on training for reading and tab order and the lack of automated tests for slides.
• Automated tools are not sufficient. The tests still miss context-dependent issues, such as whether alt text or reading order is correct, and cases that are hard to analyze, such as text over a background image or gradient.
• Context on the problem's scale. In 2020 NPSAS data, 21% of U.S. undergraduates reported having a disability; as of 2024, only 4.6% of North American CS undergraduates received disability accommodations, while 27.8% of CS departments reported offering no accommodations at all. The WebAIM Million project's 2025 survey of the top million home pages reported that 18.5% of images lacked alt text, 39% of pages had improper heading structure, and low-contrast text appeared on 79.1% of pages.
• Qualitative feedback is preliminary. The abstract describes the staff and student feedback as preliminary.

Methodology in Plain English

The authors did not run a controlled experiment. They conducted an experience report, which means they describe what they built, how they used it, and what they observed. The work proceeds in three layers.

First, a manual audit: the first author systematically walked through two introductory programming courses and recorded every accessibility barrier found, tagging each one with structured metadata — where it appeared, what format it was in, whether the content was instructionally necessary, and whether fixing it would be trivial or non-trivial. The audit lens was the POUR framework (Perceivable, Operable, Understandable, Robust), mirroring WCAG 2.1. Issues were grouped by content type (text, images/figures, video, presentation materials), and a matching remediation playbook was written for each type.

Second, technical systems to reduce how much manual remediation is needed. Course content formerly distributed as PDFs was rewritten as web pages (Markdown to HTML, with MathJax for math), because HTML supports accessibility features and easier customization than PDF. Where redesign was impractical, alternate "views" were distributed alongside the PDFs — for example the original slide source files, or HTML produced from TeX with pandoc for simple documents and tex4ht for complex ones with many macros and layout constraints. Automated tests were layered in: a fast HTML validator (the Nu HTML Checker) for mechanical validity issues, and axe-core browser tests checking WCAG 2.1 AA and AAA rules, both run locally and in CI/CD pipelines so staff got instant feedback.

Third, human systems. The authors ran accessibility trainings for TAs using interactive activities, in groups ranging from 6 to 100 participants, lasting 30 minutes to one hour, and adapted for individual, small-group, in-person, and virtual formats. They then set explicit accessibility expectations for staff and integrated accessibility topics into the student curriculum and norms. Feedback was gathered qualitatively from staff and students rather than through a formal measurement instrument.

Why This Matters

Impact on research. The paper argues that accessibility work in computing education is usually individual and reactive, and that scaling it requires treating technical infrastructure and human training as one combined problem. Its distinctive move is framing accessibility as a systems design question — audits, remediation, tooling, and training as four interlocking systems — rather than a checklist. It also reports a negative result that is useful for the field: an unglamorous accessibility topic (reading and tab order) got worse over a year precisely where neither training nor automated tests covered it, suggesting that partial efforts redistribute rather than eliminate problems. It builds on prior work such as Balik et al., Shinohara et al., and Mankoff and Mack, and notes that prior research in accessible CS education centers mostly on blind and low-vision and Deaf and Hard of Hearing students.

Real-world applications:

• Course material production: Rewriting reference sheets, glossaries, exam reference sheets, and seating charts as web-first HTML documents instead of PDFs, and distributing slide sources or converted HTML alongside PDF exports.
• Teaching-assistant onboarding: Running short, activity-based accessibility trainings and publishing explicit staff norms such as "avoid images of text" and "use structured markup for structured content," complete with an accessible Google Slides theme that the team made WCAG 2.1 AA compliant.
• Automated quality gates: Wiring an HTML validator and axe-core browser tests into existing CI/CD pipelines and course websites so accessibility regressions are caught at authoring time instead of after the fact.
• Student-facing pedagogy and community norms: Assigning modules on alt text, color contrast checkers, game design, and reflection on ASCII art captions, and asking students to replace code screenshots with text before staff answer their questions.

Industry relevance. The tooling the authors lean on — the Nu HTML Checker and axe-core in CI/CD — is mainstream web engineering tooling, and the paper's lesson that validators catch only a subset of problems (missing alt text, heading structure) while browser-based rules catch others (color contrast, link text, landmarks, tables) applies directly to production web and documentation work. The same tension applies to any organization whose content turns over faster than it can be reviewed: automated checks handle mechanical issues, but context-dependent questions such as whether alt text is correct still require a human in the loop.

Future Directions

1. Broader accessibility coverage. The current systems deliberately address a subset of issues — those with frequent accommodation needs, well-documented solutions, and areas where the team had specific expertise. The authors plan to expand to audio description, reduced motion, and dyslexia and dyscalculia, and to better support neurodivergent learners, noting that prior accessible CS education work centers mainly on blind and low-vision and Deaf and Hard of Hearing students.
2. Domain-specific accessibility issues. Open questions remain about conveying the structure of complex data structures, such as a graph or automata. The authors hope to scale existing solutions, citing Balik et al. (2013) work on GSK, an accessible graph sketching tool.
3. Improved longitudinal auditing. The authors intend to keep auditing subsequent offerings and to design better mechanisms for longitudinal evaluation that account for variability in course offerings and materials — a problem made harder by term-by-term instructor and staff rotation.
4. Engaging with broader communities. The work was conducted mostly within one institution and discipline. The authors want to collaborate with other institutions and fields beyond computing education, and to partner with organizations representing disabled students, programmers, and educators.

Target Audience

Computing educators and course staff at institutions with large courses benefit most, particularly instructors and teaching assistants who own assignment specifications, slide decks, videos, and course websites and need practical remediation strategies. Accessibility practitioners and disability services staff in higher education will find the audit classification templates and the finding that many accommodation requests were already satisfied useful. Researchers in computing education and accessible computing can use the paper as a case study and as a source of open problems, including the longitudinal slide reading-order regression and the limits of automated testing. Course and content platform developers, including those building CI/CD and web infrastructure for education, will find the validator-versus-browser-test comparison directly applicable. The paper's introductory exposition of POUR, WCAG 2.1, and the relevant law (Title II of the ADA, the Accessibility for Ontarians with Disabilities Act, the European Accessibility Act) makes it approachable for readers who are new to accessibility work.

Authors’ abstract

It is critically important to make computing courses accessible for disabled students. This is particularly challenging in large computing courses, which face unique challenges due to the sheer scale of course content and staff. In this experience report, we share our attempts to scale accessibility efforts for a large university-level introductory programming course sequence, with over 3500 enrolled students and 100 teaching assistants (TAs) per year. First, we introduce our approach to auditing and remediating course materials by systematically identifying and resolving accessibility issues. However, remediating content post-hoc is purely reactive and scales poorly. We then discuss two approaches to systems that enable proactive accessibility work. We developed technical systems to manage remediation complexity at scale: redesigning other course content to be web-first and accessible by default, providing alternate accessible views for existing course content, and writing automated tests to receive instant feedback on a subset of accessibility issues. Separately, we established human systems to empower both course staff and students in accessibility best practices: developing and running various TA-targeted accessibility trainings, establishing course-wide accessibility norms, and integrating accessibility topics into core course curriculum. Preliminary qualitative feedback from both staff and students shows increased engagement in accessibility work and accessible technologies. We close by discussing limitations and lessons learned from our work, with advice for others developing similar auditing, remediation, technical, or human systems.