WCAG checklist for e-learning

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 storyboard

Most accessibility problems are decided long before the course is built. These are the ones you can catch in a script or storyboard, when fixing them costs a sentence instead of a rebuild.

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.