A WCAG 2.1 AA Checklist for eLearning Teams

Someone has told you the course needs to be accessible. The requirement might have come from procurement, from legal, or from a learner who couldn't get through the last one, and now WCAG 2.1 AA course creation is your problem. So you go looking for the rules and land on WCAG 2.1 AA, the Web Content Accessibility Guidelines that most accessibility laws and procurement requirements point to: dozens of success criteria, almost all of them written for websites and software, not for the course you're trying to build.

The standard tells you what the rules are. It doesn't tell you where they land in a course, which is the part a course team needs before the build starts, not after an audit comes back with a list of fixes.

What follows is that standard reorganized around what's on the screen: text, color, media, interactions, navigation, and assessments. Use it as a reference from the first storyboard to the day you ship.

What is WCAG 2.1 AA, and does it apply to eLearning?

Yes, it applies. A modern course is web content, built from HTML, media, and interactions that run in a browser, so the same accessibility rules that govern any website govern your course.

WCAG 2.1 AA is the international standard for making digital content usable by people with disabilities, set at the conformance level that most laws and procurement rules require. It's organized around a few core ideas: content should be perceivable, operable, understandable, and able to work reliably with assistive technology like screen readers.

In the United States, the Revised Section 508 standards incorporate WCAG's Level A and AA success criteria by reference, so a course built to WCAG 2.1 AA meets the accessibility requirements that Section 508 points to. Other frameworks point to WCAG too, including the European Union's EN 301 549 and accessibility regulations in Canada. If you work in government, education, or healthcare, you're likely already operating under one of these.

The version number matters when a vendor uses it loosely. Version 2.1 added criteria for mobile and low-vision use that earlier versions lacked, which is why current requirements specify WCAG 2.1 AA.

The WCAG 2.1 AA course creation checklist for eLearning

This is the part the spec doesn't give you: the requirements grouped by where they show up in a course. Each group below names what to check and ties it to the relevant WCAG 2.1 AA success criterion, so you can check each item against the standard itself.

Text and structure

Structure is what lets a screen reader move through a course the way a sighted learner scans it. Headings, lists, and reading order have to be marked up as real structure that assistive technology can read.

• Headings: Use real heading levels in order so assistive technology can build a navigable outline. WCAG 2.1 AA requires that structure shown visually is also available in code (1.3.1, Info and Relationships).
• Reading order: Make sure the order a screen reader reads content matches the visual order on screen (1.3.2, Meaningful Sequence).
• Page language: Set the document language so screen readers use the correct pronunciation (3.1.1, Language of Page).
• Resizable text: Content has to stay usable when text is enlarged to 200% (1.4.4, Resize Text).
• Selectable text: Use actual text wherever an image of text would otherwise carry the words (1.4.5, Images of Text).
• Instructions that don't depend on sight: Don't rely on shape, position, or "the button on the right" alone. Name the control (1.3.3, Sensory Characteristics).

Color and contrast

Color is one of the most common failure points in courses, and it's the easiest to catch before anything is built. Check your contrast ratios, and never let color carry meaning on its own.

• Text contrast: WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, roughly 18pt or 14pt bold (1.4.3, Contrast Minimum).
• Non-text contrast: Buttons, form fields, icons, and meaningful graphics need at least 3:1 against their background (1.4.11, Non-text Contrast).
• Color is never the only signal: Don't show a required field, a right-or-wrong answer, or a progress state with color alone. Pair it with text or an icon (1.4.1, Use of Color).

Run your palette through a contrast checker during design. A brand color that fails the minimum is far cheaper to swap on a style guide than across forty finished screens.

Images and media

Every image needs a text equivalent, and every piece of audio or video needs an alternative for learners who can't hear it or see it.

• Alt text: Give informative images a text alternative that conveys their meaning, and mark purely decorative images so assistive technology skips them (1.1.1, Non-text Content).
• Captions: Prerecorded video with audio needs synchronized captions (1.2.2, Captions).
• Audio description or transcript: Video that shows information the narration doesn't state needs an audio description or an equivalent text alternative (1.2.3 and 1.2.5).
• Transcripts for audio-only: Narration or podcast-style audio needs a transcript (1.2.1, Audio-only and Video-only).
• No surprise audio: If sound plays automatically for more than three seconds, give the learner a way to pause or stop it (1.4.2, Audio Control).

Interactions and controls

Interactions like drag-and-drop, hotspots, accordions, and tabbed panels are where accessibility breaks most often, because they're built from scratch and the accessibility has to be built along with them.

• Name, role, value: Every interactive control has to tell assistive technology what it is, what it does, and what state it's in (4.1.2, Name, Role, Value). A box styled to look like a button isn't a button unless it's coded as one.
• No mouse-only actions: Anything done with a drag or a multi-finger gesture needs a single-tap or keyboard alternative (2.5.1, Pointer Gestures).
• Feedback that gets announced: When a result appears without moving focus, such as "3 of 5 correct," it has to be announced to screen readers (4.1.3, Status Messages).
• Stable hover and focus content: Tooltips and pop-ups triggered on hover or focus must be dismissible and stay put long enough to read (1.4.13, Content on Hover or Focus).

Navigation and keyboard

A learner who can't use a mouse has to be able to finish the entire course with a keyboard. This one is frequently missed in players built from scratch.

• Full keyboard operation: WCAG 2.1 AA requires every interactive element to be operable by keyboard (2.1.1, Keyboard).
• No keyboard traps: Focus has to be able to move into a component and back out again without getting stuck (2.1.2, No Keyboard Trap).
• Visible focus: The element that currently has keyboard focus must be clearly indicated on screen (2.4.7, Focus Visible).
• Logical focus order: The order focus moves through the screen has to make sense and follow the content (2.4.3, Focus Order).
• More than one way through: In courses with many pages, give learners a way past repeated navigation and more than one way to find content (2.4.1 and 2.4.5).

Assessments and forms

Quizzes and input fields carry their own requirements, because a learner has to understand the question, know when an answer is wrong, and be able to fix it.

• Labels and instructions: Every input needs a clear label that's connected to it in code so assistive technology can pair the two (3.3.2, Labels or Instructions).
• Error identification: When an answer is wrong or a field is invalid, say so in text and point to what needs to change (3.3.1 and 3.3.3).
• Adjustable timing: If a quiz is timed, learners need to be able to turn off, adjust, or extend the limit, unless the timing itself is part of what's being tested (2.2.1, Timing Adjustable).
• Consistent controls: A button that does the same thing should be labeled the same way everywhere it appears (3.2.4, Consistent Identification).

Where do eLearning courses most commonly fail WCAG 2.1 AA?

The failures cluster in a handful of predictable places: color contrast, missing captions and alt text, and interactions that work with a mouse but not a keyboard. None of them are exotic, and all are catchable before launch.

Part of why they slip through is the mismatch this checklist exists to fix. The standard is organized by principle, and a course is organized by screen, so criteria that don't map cleanly onto a single page are easy to overlook. The same set of requirements shows up again in onboarding courses that meet the standards, where high new-hire volume makes a repeatable checklist especially useful.

How do you build accessibility in from the start instead of retrofitting?

Build it in from the first storyboard. Retrofitting accessibility into a finished course costs more and produces a worse result, because the things most likely to fail (semantic structure, keyboard operation, color choices) are locked in early and costly to revisit later.

In practice, it comes down to a few production habits that keep accessibility out of a last-minute cleanup pass. Choose the color palette against the contrast minimums before visual design is locked. Write alt text and captions as the content is created, while the person writing them still remembers what each image is for. Build interactions to work with a keyboard from the first version, and test with a keyboard and a screen reader as the build progresses. The cost difference between designed-in and bolted-on is one reason we treat accessibility as a core part of building SCORM and WCAG-compliant eLearning.

If you're rolling training out across many locations, such as franchises or regional branches, one accessible standard applied to every course is also what keeps the catalog consistent and compliant as it grows.

Who's responsible for WCAG compliance, and what should you ask a vendor?

Accessibility is the responsibility of whoever builds the course, and if you're buying it, the responsibility to verify the claim sits with you. A vendor who says "WCAG 2.1 AA" without saying how they checked has given you a claim, not evidence.

When you're evaluating a provider, a few questions separate real accessibility work from a checkbox. Ask which version and level they build to, and look for a specific answer like WCAG 2.1 AA. A vague "it's accessible" or "it's 508 compliant" usually means no one has checked against the actual criteria. Ask how they test, because automated scanners catch only part of the picture; treating accessibility as part of instructional-design quality means manual keyboard and screen-reader testing on top of the scan. Ask whether the accessibility review is included in the price or billed separately, and ask to see a sample course you can test yourself.

How Express eLearning handles accessibility

Express eLearning includes WCAG 2.1 AA accessibility review in every course, as part of the flat price. Express eLearning by Neovation is a productized eLearning development service that delivers a professional, SCORM-compliant course in approximately 10 business days for $1,999. Every course is designed and quality-checked by Neovation's instructional designers and developers, packaged as SCORM 1.2 or SCORM 2004, and delivered with client-owned HTML5/JS source files, so accessibility travels with the course no matter where you host it.

Accessibility built into the price isn't the right answer for every project. A course that needs branching simulations with real consequences, custom voiceover, or fully custom visual design beyond the productized scope belongs with Neovation Custom Learning. If you have the in-house team and tools to build and test for accessibility yourself, that can work too. But if you need a professional, accessible course on a fixed timeline and budget, send us your source material and we'll tell you what it would take.