Understanding the Motivations of Final-year Computing Undergraduates for Considering Accessibility
Paula Conn, Taylor Gotfrid, Qiwen Zhao, Rachel Celestine, Vaishnavi Mande, Kristen Shinohara, Stephanie Ludi, Matt Huenerfauth · 2020 · ACM Transactions on Computing Education (TOCE), Vol. 20, No. 2, Article 15 · doi:10.1145/3381911
Summary
This 22-page ACM Transactions on Computing Education article asks a question that most accessibility education research has side-stepped: what happens to students’ motivation to build accessible technology two years after a required accessibility-education intervention? Rochester Institute of Technology (RIT) embeds one week of required accessibility lectures in its mandatory HCI course for Software Engineering and Information Technology undergraduates (covering prevalence of disability, physiology and senses, assistive technologies, accessible web authoring, simulation and testing tools including WAVE, and guidelines including WCAG and the ADA). The authors conducted a three-phase longitudinal mixed-methods study: Phase 1 was the intervention itself; Phase 2 was semi-structured 45-minute interviews with 16 final-year SE or IT students who had taken the HCI course roughly two years earlier and had also completed at least one 3-5 month paid internship, analysed via Grounded Theory (open, axial, and selective coding by three researchers); Phase 3 was a survey of 114 additional final-year computing students (including Computer Science, which has overlapping core curriculum) asking Likert-scale and ranked questions about which accessibility topics, resources, and course structures they believed would have prepared them better. The research sits within a legal and industry context: the 21st Century Communications and Video Accessibility Act, the ADA, ABET’s 2018 accreditation requirement covering accessibility, TeachAccess’s industry-university outreach, and the 2018 surge in web-accessibility lawsuits. IRB-approved; participants received $20 (interviews) or $10 (surveys).
Key findings
Fourteen of 16 interview participants reported that they were not motivated to develop their accessibility skills after the course. Three detractor themes emerged. First, the learn-it-on-your-own culture of computing: students described professors and managers as 'hands-off,' pushed them to Google answers, and this extended to accessibility — but where for programming languages self-teaching works reasonably well, for accessibility it leaves students without the human-centred grounding (interactions with disabled users, disability etiquette) that the skill actually demands. Second, not being required: both course projects and internships almost never mandated accessibility, and the 7 of 15 who did consider it in their internship did so only because it was an explicit job requirement (P14: 'It was my job'). Third, not seeing it as essential career preparation: students framed accessibility as a front-end niche relevant only to healthcare, government, or access services, and their co-workers reinforced this by Googling accessibility each time rather than having baseline skills. The two exception participants had been motivated by deep interactions with disabled individuals plus a formal mentorship arrangement (one an NSF REU, one a required independent study with an accessibility faculty mentor). Survey preferences lined up: top topics were testing software, gathering requirements, and integration into the SDLC; top resources were APIs/frameworks with built-in accessibility, examples of accessible technologies, and guidelines (Dunn’s post-hoc p < 0.001 against lower items); top course structure was an elective accessibility course (significantly preferred over required integration, p = 0.001-0.006).
Relevance
For accessibility educators and industry practitioners, this paper is a sobering corrective to the short-term success stories elsewhere in the computing-education literature: a one-week lecture module, even when delivered well, does not translate into long-term motivation when the surrounding curriculum and workplace culture treat accessibility as optional. The paper argues that curriculum-level changes (integration throughout, not a single elective), mentorship structures, and extrinsic reinforcement (job requirements, peer expectation, ABET compliance) all have to move together — students’ own preferred intervention (an elective) is precisely the structure that will perpetuate the problem, because it lets students opt out. For hiring managers, the finding that accessibility becomes a requirement only when someone makes it one is a direct argument for including accessibility in job descriptions, code-review rubrics, and internship learning outcomes. Limitations: single-institution sample (RIT, which actually has above-average DHH presence on campus), small interview sample (n=16), survey respondents skewed male (96 of 114), and self-report only. The findings likely generalise to comparable US computing programmes but not to countries with mandatory accessibility courses.
Tags: accessibility education · computing education · pedagogy · professional development · qualitative research · accessibility research
Standards referenced: WCAG · ADA · Section 508 · 21st Century Communications and Video Accessibility Act