Accessible e-Learning: Applying WCAG 2.2 to Courses

An e-learning course is not a document with a play button. It is a small web application: a player with custom navigation, timed audio and video, interactions the learner has to operate, a quiz engine that scores them, and a SCORM or xAPI wrapper that reports back to a learning management system. Every one of those moving parts is a place where accessibility can quietly break, which is why a course can pass a casual review and still lock out a learner who relies on a keyboard or a screen reader.

The good news is that there is no separate standard to learn. Courses are web content, so they are judged against the same WCAG 2.2 Level AA criteria as any website, and packages shipped through an LMS should be authored and tested against that benchmark directly. The harder news is that the course format creates failure modes documents never face. This post walks through where WCAG 2.2 actually bites in course production — captions, keyboard, focus, colour and the LMS-specific traps. We covered the regulatory backdrop and the European Accessibility Act in a companion post on documents; here the subject is the course itself.

A static PDF has a reading order, some tags and a set of links; once those are right, they tend to stay right. A course adds layers a document never has. The player wraps your content in its own chrome — a menu, a seekbar, previous and next buttons — and that chrome is frequently built from styled containers rather than real buttons, so a screen reader announces nothing and a keyboard cannot reach them. On top of that sit the interactions — drag-and-drop sorting, hotspots, branching scenarios, timed knowledge checks — each one custom code, and custom code is where accessible names, roles and keyboard handling get forgotten.

The second difference is time. Documents are static; courses move. Narration plays, animations run, slides advance, and a learner using assistive technology has to stay oriented while the screen changes under them. If focus is not managed when a new slide loads, a screen-reader user is dropped back at the top of the player on every transition and has to hunt for the new content. None of this is exotic; it is exactly what a documents-only accessibility checklist misses.

Most courses carry a voice-over track, and many carry video. Audio that conveys information needs a synchronised text alternative, which in practice means accurate captions on every video and a transcript for narration that is not already mirrored on screen. Auto-generated captions are a starting point, not a deliverable: they mangle terminology, drop speaker changes and punctuate badly, and in a compliance or technical course the errors land precisely on the words that matter most.

Purely visual information needs the reverse treatment. When an animation or a silent demonstration shows something the narration does not describe, a learner who cannot see it gets nothing, so the meaning has to be carried in audio description or an accessible text equivalent. This is far cheaper to handle at the storyboard stage, before voice-over is recorded — one more reason the storyboard is the right place to draft alt text and record what each visual is for.

Keyboard operability is the single highest-value thing to get right, because it underpins screen-reader use and helps anyone who cannot use a mouse precisely. The rule is blunt: every interaction has to be operable from the keyboard, with a visible focus indicator, a sensible tab order, and no traps that strand focus inside a widget. Custom controls need real semantics — an accessible name and the right role — so a button announces itself as a button and reports its state as pressed or expanded.

Drag-and-drop interactions deserve particular attention, and WCAG 2.2 made this explicit. The new Dragging Movements criterion requires that anything achievable by dragging can also be done with a single pointer action, and for keyboard users a drag-based sorting or matching activity needs a genuine non-drag path — select-then-place, or a set of buttons — not a mouse-only gesture with no alternative. The same discipline applies to hotspots, sliders and any control a developer invents for a single screen.

Two of WCAG 2.2's additions speak directly to course interfaces. Focus Not Obscured requires that the element with keyboard focus is not hidden behind something else — and a course player is full of candidates: a sticky top bar, a slide-over menu, a feedback layer that pops up over the content. If pressing Tab moves focus to a control that is then covered by the player chrome, a sighted keyboard user loses their place even though focus technically moved.

Target Size (Minimum) addresses the small, fiddly controls courses love: the row of dots that marks slide progress, a tiny close button on a pop-up, markers scattered across an interactive diagram. Controls that carry a function need to be large enough to hit reliably — meeting WCAG 2.2's minimum target size [HV: verify before publish — 2.5.8 Target Size (Minimum) is 24 by 24 CSS pixels, with listed exceptions] — or to have enough spacing around them to compensate. These are not edge cases; they are parts of the player learners touch on every screen, and easy to fix in the theme once someone looks for them.

Courses lean on colour to carry meaning, and that is where many of them fail. Feedback that turns an answer green for right and red for wrong communicates nothing to a learner who cannot distinguish the two, so correctness has to be signalled with text or an icon as well as colour. The same goes for required fields, status indicators and anything in a diagram set apart only by hue. Colour can reinforce meaning; it cannot be the only thing that carries it.

Contrast is the companion requirement. Body text, button labels and any graphic that conveys information have to meet the contrast thresholds WCAG sets [HV: verify before publish — WCAG 1.4.3 requires 4.5:1 for normal text and 3:1 for large text; 1.4.11 requires 3:1 for meaningful non-text], which rules out the low-contrast grey-on-white and pale brand palettes that look elegant in a mock-up and vanish on a projector. Timing matters too: learners need to be able to pause or control moving content, and nothing in a course should flash in a way that could trigger seizures.

Some of the most stubborn course-accessibility problems live in the wrapper, not the content. A SCORM or xAPI package usually runs inside an iframe served by the LMS, and that boundary is where focus order, document titles and screen-reader announcements get confused — a course that is perfectly navigable when you open the HTML directly can behave very differently once the LMS launches it. So testing has to happen on the actual target platform, not just the authoring tool's preview.

WCAG 2.2's quieter additions show up here too. Redundant Entry means a multi-part assessment should not force learners to re-enter information they have already given; Consistent Help means a help or contact affordance should sit in the same place throughout; and Accessible Authentication, while it usually applies to the LMS login rather than the package, is worth raising with the platform owner because it gates access to every course behind it. They are easy to overlook because they straddle the line between the course and the system around it.

Accessibility is cheapest as a production default rather than a remediation project. It starts in the storyboard, where alt text is drafted and interactions are specified with a keyboard path in mind, and continues into a WCAG-aware build where the player theme, the custom controls and the quiz engine are accessible by construction. A course written this way needs far less rework than one audited at the end, when fixing the interaction model can mean rebuilding it.

Testing then has to be real. Automated checkers catch only a fraction of WCAG failures — useful for contrast and missing names, blind to whether a drag-and-drop can actually be completed without a mouse — so a manual pass with a screen reader on the target LMS is not optional. We treat accessible courseware as part of e-learning delivery and run the screen-reader testing and retesting through the same accessibility practice that handles our WCAG 2.2 and Section 508 work, so a course is judged by whether a learner using assistive technology can finish it, not by whether a tool reported zero errors.