WCAG, the Web Content Accessibility Guidelines, is the standard most organizations use for accessible digital content, e-learning included. It's also famously hard to read. This checklist translates the WCAG 2.1 and 2.2 Level AA criteria that matter most in courses into plain questions, split by when you can catch them: while you design, and after you build.
Design stage: what you can fix in the design document or storyboard
Most accessibility problems are decided long before the course is built. These are the ones you can catch in a script or a design document or storyboard, when fixing them costs a sentence instead of a rebuild.
Design-stage issues are decided in the design document or storyboard. Build-stage issues only show up once the course is built.
Design stage: fix in the design document or storyboard
You, in the script or the design document or storyboard, where a fix costs a sentence.
- Alt text says what an image means in context.
- Text descriptions carry what charts and diagrams show.
- Captions and transcripts for every video and audio clip.
- Color never carries meaning alone.
- Instructions don't depend on shape, position, or sound.
- Link and button text says where it goes.
- Time limits can be turned off, adjusted, or extended.
- Drag-and-drop has a click or keyboard alternative.
Build stage: test in the finished course
A tester, in the published output, with a checker, a keyboard, and a screen reader.
- Keyboard works alone, and focus never gets trapped.
- Focus is always visible and moves in a logical order.
- Contrast is 4.5:1 for text, 3:1 for large text and controls.
- Zoom to 200% and reflow at narrow widths lose nothing.
- Click targets are at least 24 by 24 pixels.
- Custom interactions expose name, role, and state.
- Titles and language are set on every screen.
Automated checkers like axe and WAVE help with the build stage. They can't judge design calls, like whether alt text is meaningful.
Images and visuals
- Every meaningful image has alt text that says what it means in context, not just what it is. (1.1.1)
- Decorative images are marked decorative so screen readers skip them. (1.1.1)
- Charts, diagrams, and infographics have a text description that carries the same information. (1.1.1)
- No important text is baked into images. (1.4.5)
Audio and video
- Every video with speech has accurate captions. (1.2.2)
- Audio-only content, like a podcast segment, has a transcript. (1.2.1)
- If a video shows information that isn't spoken, there's audio description or a text alternative that covers it. (1.2.3, 1.2.5)
- Nothing plays automatically for more than a few seconds without a way to pause or stop it. (1.4.2, 2.2.2)
- Nothing flashes more than three times a second. (2.3.1)
Text, color, and instructions
- Meaning is never carried by color alone. "Correct answers are in green" also needs an icon or a word. (1.4.1)
- Instructions don't depend on shape, position, or sound alone. Not "click the round button on the right". (1.3.3)
- Headings and lists are real headings and lists, in a logical order. (1.3.1, 2.4.6)
- Link and button text says where it goes or what it does. Not "click here". (2.4.4)
- Language is as plain as the content allows, and new terms are defined.
Interactions and quizzes
- Timed activities and quizzes let learners turn off, adjust, or extend the time limit. (2.2.1)
- Every drag-and-drop has a single-click or keyboard alternative. (2.5.7, new in 2.2)
- Form fields and quiz options have clear labels and instructions. (3.3.2)
- Errors are explained in words, with a hint about how to fix them. (3.3.1, 3.3.3)
- Help, like a glossary or support link, appears in the same place on every screen. (3.2.6, new in 2.2)
- Navigation is consistent from screen to screen. (3.2.3)
Build stage: what you test in the finished course
These depend on the authoring tool, the player, and how the course was built. Test them in the published output with an automated checker, a keyboard, and ideally a screen reader.
- Everything works with a keyboard alone, and focus never gets trapped. (2.1.1, 2.1.2)
- The keyboard focus is always visible and never hidden behind other content. (2.4.7, 2.4.11 new in 2.2)
- Focus moves through the screen in a logical order. (2.4.3)
- Text contrast is at least 4.5:1, or 3:1 for large text. (1.4.3)
- Buttons, controls, and focus indicators have at least 3:1 contrast against their background. (1.4.11)
- Text can be enlarged to 200% without losing content, and content reflows at narrow widths. (1.4.4, 1.4.10)
- Click targets are at least 24 by 24 pixels, or spaced so they're easy to hit. (2.5.8, new in 2.2)
- Custom interactions expose their name, role, and state to assistive technology. (4.1.2)
- Each screen or page has a descriptive title, and the language is set. (2.4.2, 3.1.1)
Where tools fit
Automated checkers like axe and WAVE are excellent at the build-stage items they can detect, like contrast and missing labels, and they should be part of your QA. They can't tell you whether alt text is meaningful, whether a chart's description carries the same information, or whether an instruction depends on color. Those are design judgments, and they're cheapest to fix before anything is built.
Catching the design-stage issues early
Pedagrade reviews a course's content against WCAG 2.1 AA at the design stage: hollow or missing alt text, missing captions and transcripts, meaning carried by color, vague link text, instructions that depend on seeing or hearing. It complements an automated scan of the built course. It doesn't replace one. For files and builds you already have, Pedagrade's Course files check reads Word, PowerPoint, PDF, and course exports, and Playtest has a keyboard-only test learner take the finished course.
See what it finds in your course.
Paste a course or upload the file. In about a minute you get a scored report with every finding cited and the fix written for you. Free for a week, no card needed. Working in ChatGPT, Claude, Word, or Google Docs? Use it there.
Start your free week