Accessibility Testing SOP: A Standard Process for eLearning Teams

Questions answered by this guide

• ?What is an accessibility testing SOP?
• ?Who should be responsible for accessibility testing on an eLearning team?
• ?How often should accessibility testing happen?
• ?What's the difference between a checklist and a testing process?
• ?How do we document that accessibility testing actually happened?

What you'll learn

• A checklist tells you what to check on one course. An SOP tells your team how testing happens every time, for every course
• Combine automated scanning with manual keyboard and screen reader testing, neither alone is sufficient
• Document who tested what and when, so testing is auditable, not just assumed to have happened

What's inside

L&D managers and QA leads setting up a repeatable accessibility testing process for a team

1. 01Why a one-time checklist isn't a process
2. 02Roles and responsibility
3. 03Tools and methods to combine
4. 04Cadence: when testing happens
5. 05Documentation and sign-off

Why it matters

A checklist run once by whoever remembers to run it isn't a process, it's a habit that depends on one person. A real SOP survives someone leaving the team, a tight deadline, or a course being edited six months after it first shipped. Without one, accessibility testing quietly stops being reliable exactly when it matters most, under time pressure.

When you'll encounter this

• You're setting up how a team, not just yourself, handles accessibility testing.
• Testing currently depends on one person remembering to do it.
• A course that passed review once was edited later and nobody re-tested it.
• A stakeholder or client asks how your team verifies accessibility, and there's no clear answer beyond "we check it."

Best practices

• Assign accessibility testing responsibility to a role, not a specific person, so the process survives staff changes. It doesn't have to be a full-time job, it has to be someone's clearly stated job.
• Combine three methods, not one: an automated scan (fast, consistent, catches structural issues at scale), a manual keyboard-only pass (catches what a scan can't judge, like whether tab order actually makes sense), and a periodic real screen reader read-through (catches what neither of the other two can).
• Test at three points, not one: once when a course is built, again right before publishing (content can drift during review), and again after any substantive edit post-launch.
• Record what was tested, how, and by whom, even a simple shared log is enough. The goal is being able to answer "was this tested?" with evidence, not memory.
• Review the SOP itself periodically, a process that made sense for one course a year ago might not fit a different kind of course today.

Common mistakes

• Relying on a single method, usually just an automated scan, and treating a clean result as a complete accessibility review.
• Testing once at launch and never again, even after later edits change what's actually published.
• Making accessibility testing one specific person's informal responsibility instead of a defined role, so it quietly stops happening when that person is busy or leaves.
• Having no record of testing having happened, so a compliance question later has no evidence to point to.

Practical checklist

• A specific role, not just a person, is responsible for accessibility testing.
• Automated scanning, manual keyboard testing, and periodic screen reader testing are all part of the process, not just one of the three.
• Testing happens at build, pre-publish, and after any substantive post-launch edit, not just once.
• Testing activity is logged somewhere the team can point to later.
• The SOP itself is reviewed periodically, not treated as permanently finished.

Frequently asked questions

Summary

A checklist tells you what to check once. An SOP is what makes accessibility testing happen reliably, every course, every time, regardless of who's on the team or how tight the deadline is: a defined role, three combined testing methods, three points in the course lifecycle, and a real record that it happened.