eLearning accessibility: a practical WCAG 2.2 checklist

Accessible eLearning should be usable by people with different visual, auditory, motor and cognitive needs. WCAG 2.2 organises web accessibility around four principles: content should be perceivable, operable, understandable and robust.

Authoring tools can support accessibility, but they cannot make every design choice accessible automatically. Course authors still control wording, reading order, alternative text, captions, interaction design and much of the learner experience.

• Use a logical heading hierarchy rather than styling ordinary text to look like headings.
• Keep reading and focus order meaningful when layouts contain columns, cards or overlays.
• Use descriptive link and button text rather than repeated “click here” labels.
• Give pages and sections clear names so learners know where they are.

Test the published course with keyboard navigation because the visual layout does not always reveal the programmatic order.

Every essential control should be usable without a mouse. Move through the course with Tab, Shift+Tab, Enter, Space and other expected keys. Focus should be clearly visible and should not disappear behind sticky headers, dialogs or other content.

Avoid interactions that require precise dragging when the same outcome can be achieved with buttons, selection or another single-pointer alternative.

Text and meaningful interface elements need sufficient contrast against their backgrounds. Do not use colour alone to show correct/incorrect, required/optional or selected/unselected states.

Combine colour with text, icons, patterns or another perceivable cue. Check contrast in the actual published output, not only the design file.

Write alternative text that communicates the purpose of informative images in context. Decorative images should be ignored by assistive technology where the authoring tool supports that behaviour.

Do not place essential paragraphs inside images. For diagrams, charts or screenshots containing important relationships, provide an equivalent text explanation when a short alt attribute cannot convey the meaning.

Provide accurate captions for meaningful spoken audio in video and a transcript or equivalent where appropriate. Important visual information that is not explained in the audio may require audio description or an alternative description.

Give learners control over autoplaying or moving content. Avoid flashes that can create seizure risk, and do not make time limits unnecessarily strict.

Instructions should identify what the learner needs to do before the interaction begins. Form controls need meaningful labels, and error messages should explain the problem rather than relying on red outlines alone.

For quizzes, ensure options have accessible names, keyboard selection works, focus moves predictably and feedback can be discovered by screen-reader users.

1. Complete the whole course using keyboard only.
2. Check focus is always visible and not obscured.
3. Zoom text and inspect responsive layouts.
4. Check headings and reading order.
5. Review every informative image for meaningful alt text.
6. Confirm captions and transcripts.
7. Check colour contrast and colour-independent cues.
8. Test questions, errors, dialogs and menus.
9. Use automated checks where available, then perform manual testing because automation cannot judge every requirement.

WCAG conformance is broader than a checklist, and legal obligations vary by context. Use the current W3C WCAG 2.2 material as the authoritative reference.

Accessibility should also be included in the wider course-development workflow, not added just before launch.