Accessible e-learning: WCAG 2.2 AA checks for courses, quizzes and forums

01

Captions, transcripts and audio description

Every prerecorded video with speech needs synchronised captions. Automatic captions are a useful first draft, but names, product terms and numbers must be corrected by a person before publishing, because a wrong figure in a safety or compliance lesson is a content error, not a cosmetic one.

Add a text transcript below each video and audio lesson. Transcripts help deaf and hard-of-hearing learners, people on slow connections and anyone who wants to search or skim. When important information is shown only visually, such as a diagram being drawn or a step demonstrated without narration, describe it in the narration or provide audio description, which WCAG 2.2 requires at level AA for prerecorded video.

02

Keyboard flows for quizzes, uploads and course players

Put the mouse away and complete a whole course with Tab, Shift+Tab, Enter, Space and the arrow keys. You should be able to start the lesson, play and pause video, answer every question type, upload an assignment and submit, without getting stuck inside an embedded player. Focus must always be visible and must not be hidden behind sticky headers or chat widgets, a check WCAG 2.2 added explicitly.

Drag-and-drop questions are the most frequent failure. WCAG 2.2 requires a single-pointer alternative for dragging movements, so offer a select-and-place or dropdown version of the same question. Timed quizzes need a way for learners to extend or turn off the limit, unless the time limit is essential to what you are assessing. Clickable targets should be at least 24 × 24 CSS pixels, or have enough spacing around them.

03

Contrast, focus and readable layout

Body text needs a contrast ratio of at least 4.5:1 against its background, and large text at least 3:1. Interface elements that convey meaning, such as quiz option borders, progress bars and focus indicators, need at least 3:1 against adjacent colours. Do not rely on colour alone for feedback: a wrong answer should say “Incorrect” in text as well as turning red.

Courses must still work when text is enlarged to 200% and when the screen is 320 CSS pixels wide, without forcing learners to scroll in two directions. Slide-based packages exported at a fixed size often fail this; prefer responsive output from your authoring tool, or build key lessons natively in the platform.

04

Alt text and structure inside the editor

Authors decide most of the accessibility of a course, so the editor should make the right choice easy. Ask for alternative text whenever an image is inserted, with a clear option to mark purely decorative images. Alt text describes the purpose of the image in context: “Correct grip on the handle, thumb on top” is useful, “image1.png” is not.

Use real headings for lesson structure, real lists for steps and real tables for comparisons, not bold text or images of tables. Links should say where they go. PDF handouts need tags and a reading order, or an accessible HTML version of the same content.

05

Forums and community spaces

Discussion spaces are where accessibility is most often forgotten. The rich-text editor must be usable with a keyboard and announce its formatting buttons to screen readers. New replies and moderation notices should be announced politely without moving focus away from what the learner is typing.

Form errors must be described in text next to the field, and posting should never depend on solving a visual puzzle. Sign-in should allow password managers and pasting codes, which WCAG 2.2 covers under accessible authentication. Keep help in the same place on every page, so learners always know where to ask.

06

Mobile parity

Many learners complete mandatory training on a phone. Every activity available on desktop should work on mobile with the same result recorded, including uploads and quizzes. Test with VoiceOver on iOS and TalkBack on Android, in portrait and landscape, and confirm that pinch-zoom is not disabled.

07

How to audit a course catalogue

Combine automated checks with manual testing. Automated tools catch missing alt attributes and low contrast quickly, but only a person can judge whether alt text is meaningful or a keyboard flow makes sense. A practical audit picks a representative sample: one course of each template, every question type, the forum, sign-in and the certificate download.

• Captions checked by a person on every video; transcripts published.
• Whole course completed with keyboard only, focus always visible.
• Every drag-and-drop question has a single-pointer alternative.
• Timed quizzes can be extended or the limit turned off.
• Text contrast ≥ 4.5:1, interface contrast ≥ 3:1, feedback not colour-only.
• Layout works at 200% zoom and 320 CSS pixels wide.
• Images have meaningful alt text or are marked decorative.
• Forum editor, errors and sign-in work with a screen reader.
• Results recorded the same way on mobile and desktop.

08

Accessibility in RDCopilot eLearning

RDCopilot eLearning is built to WCAG 2.2 AA and EN 301 549: keyboard-first quiz types with alternatives to dragging, captions and transcripts on video lessons, alt-text prompts in the editor, visible focus, and moderated discussion spaces that work with screen readers. Learners sign in with their RDCopilot account, and their progress reaches HR and Reports the same way whichever device they use.

When you bring existing courses, we run the audit above on a sample during setup and list what needs fixing in the source packages. Setup is a one-off fee; the monthly licence covers EU hosting, updates, backups and support, and remediation work beyond that is billed at a fixed hourly rate.