Questions answered by this guide
- Who should be responsible for accessibility testing on an eLearning team?
- Do we need a dedicated accessibility specialist?
- Should every instructional designer test their own work for accessibility?
- What's the difference between distributed responsibility and a QA gate?
What you'll learn
- The one wrong answer is no clearly assigned owner, not any particular structure
- Three real models: dedicated specialist, distributed among IDs, or a QA gate before publishing
- The right choice depends on team size and how much accessibility expertise already exists on the team
What's inside
L&D managers and team leads deciding how to assign accessibility testing responsibility
- 01The one wrong answer
- 02Model 1: a dedicated specialist
- 03Model 2: distributed across every ID
- 04Model 3: a QA gate before publishing
- 05Choosing based on your team
Why it matters
When accessibility testing has no clearly assigned owner, it becomes everyone's job in theory and no one's job in practice, the first thing skipped under a deadline. The specific model a team chooses matters less than that a real model exists and everyone knows what it is.
Best practices
- Model 1, a dedicated specialist: best when a team is large enough to keep one person consistently busy with testing, and when deep, evolving accessibility expertise matters more than speed. Real tradeoff: testing becomes a bottleneck if that one person is out or overloaded.
- Model 2, distributed among every ID: best on a smaller team where everyone can be trained to a working competence. Real tradeoff: quality varies by person, and expertise never gets as deep as a dedicated specialist's.
- Model 3, a QA gate before publishing: a separate reviewer or team checks every course before it goes live, regardless of who built it. Real tradeoff: catches problems late in the process, after most of the build work is already done, unless paired with earlier self-review.
- Whichever model you choose, pair it with Accessibility Testing SOP so the process survives who specifically holds the role.
Common mistakes
- Assuming accessibility testing will happen because it's "part of the job" for instructional designers, without naming who specifically owns it.
- Relying entirely on Model 3 (a QA gate) with no earlier self-review, so every problem is caught at the most expensive possible point.
- Choosing Model 1 (a dedicated specialist) on a team too small to keep that role staffed reliably, creating a single point of failure.
Frequently asked questions
Can a small team really afford a dedicated accessibility specialist?
Often not full-time, but the role can exist part-time, as one clearly assigned responsibility among several someone holds, rather than a full headcount. The point is a named owner, not a job title.
Which model catches the most problems?
None of the three alone, each model changes when and by whom problems are caught, not whether a real testing process, see Accessibility Testing SOP, is actually followed underneath it.
Related Guides
Accessibility Testing SOP: A Standard Process for eLearning Teams→
A repeatable process, not a one-time checklist, for how a team tests accessibility: who's responsible, what tools and methods to use together, how often to test, and how to document that testing happened.
Building an Accessibility Testing Process That Actually Sticks→
Writing a testing process down is the easy part. Most fail quietly a few months later, skipped under deadline pressure, forgotten after the person who set it up moves on, or never actually enforced. Here's what makes a process survive past its first quarter.
Course Review Checklist: A Role-Based Process for Reviewing eLearning→
Before You Publish Checklist is one person's fast pass right before hitting publish. This is the process a course goes through to get there: who reviews what, in what order, before anyone signs off. Use this when more than one person touches a course before it launches.
A11yCheck's Review Methodology→
A11yCheck reviews a real, rendered Storyline or Rise course, not its source file, using a headless browser to open the published output the way a learner actually would, then runs three separate passes: Accessibility (deterministic, WCAG-grounded), Course Quality (deterministic, structural), and Course Engagement (advisory, AI-assisted). Here's exactly how each one works, and where the line between automated and human review actually sits.
Summary
There's no single right structure for who owns accessibility testing, dedicated specialist, distributed across the team, or a QA gate, all work, each with a real tradeoff. The only wrong answer is no clearly assigned owner at all.
Review your course before you publish it.
A11yCheck reviews Storyline and Rise courses for:
- Accessibility
- Course Quality
- Course Engagement
www.a11ycheck-dev.com