How to Make eLearning Accessible – WCAG for Course Builders

You've built a course you're proud of, and then someone asks whether it's accessible, and you realize you aren't sure what that means in practice. Does it need a special player? Do you have to rebuild everything? Is there a checklist somewhere that doesn't read like a legal document? The good news is that accessible eLearning is mostly about consistent habits, not heroics. How do you make an eLearning course accessible, and what do the Web Content Accessibility Guidelines (WCAG) actually ask of course builders?

You make eLearning accessible by building every course so people can perceive, operate and understand it whether they use a mouse, a keyboard, a screen reader, captions, magnification or none of those. In practice, that means real text with clear structure, enough color contrast, meaningful alt text, captions and transcripts for media, keyboard access to every interaction, visible focus, no surprise time limits and a player that works with assistive technology. WCAG at Level AA is the usual target, and most organizations treat them as the standard. Start with five quick tests and fix what they reveal, and you'll catch the most common problems before a learner ever runs into them.

What Does WCAG Mean for Accessible eLearning?

WCAG is the international standard for digital accessibility, published by the World Wide Web Consortium (W3C). It's written for web content, and since most courses are delivered through a browser, it applies to eLearning too. The W3C introduction to web accessibility is a short, readable starting point if you're new to the topic.

WCAG is organized around four principles, often remembered by the acronym POUR:

• Perceivable: people can see or hear the content, or get it another way (alt text, captions, enough contrast).
• Operable: people can use every control, including with a keyboard alone, and have enough time.
• Understandable: content and navigation are clear and predictable, and errors are explained.
• Robust: content must be built so screen readers and other assistive technologies can interpret it reliably.

Each guideline has success criteria at three levels: A (minimum), AA (the common target) and AAA (enhanced). When a contract or policy says a course must be "WCAG compliant," it almost always means Level AA. Check which version is named, too, because WCAG 2.0, 2.1 and 2.2 are all still referenced. Version 2.1 added several criteria that matter for mobile and low-vision learners, such as reflow and non-text contrast, and 2.2 (October 2023) added more, such as minimum target sizes and alternatives to dragging.

Who Benefits From Accessible eLearning?

Everyone does, though some learners can't use a course at all without it. Accessibility is often framed as something for a small group, and that framing is wrong because it leads to poor decisions.

Think about who takes your courses: people who are blind or have low vision, people who are Deaf or hard of hearing, and people with dyslexia, ADHD or memory difficulties. Include people with tremors, arthritis or a repetitive strain injury who can't use a mouse comfortably. Add the people with temporary limits, like a broken wrist or an eye infection, and the people in tough situations, like a technician in a loud plant who can't hear narration or a new hire reading in a second language.

Captions help in noisy break rooms and quiet open offices, keyboard access helps power users, and clear structure helps everyone skim. When you design for the edges, the middle gets a better course too.

Structure and Text: The Foundation

Everything else is easier when the foundation is right. Screen reader users move through a page by headings, lists and links, so those need to be real, not just visual styling.

• Use real headings in a logical order instead of large bold text.
• Use real lists for lists.
• Keep text as live text, not text baked into images.
• Write link and button labels that make sense out of context ("Download the checklist," not "Click here").
• Set the language of the course so screen readers pronounce words correctly.
• Check the reading order in your authoring tool. It often follows the order objects were added, not the order they appear.

Plain language is part of accessibility too. Short sentences, common words and defined terms help people with cognitive disabilities, people reading in a second language and, honestly, everyone in a hurry.

Color and Contrast

Text needs enough contrast against its background to be readable by people with low vision or color vision deficiency, and by anyone squinting at a laptop in a sunny room. WCAG Level AA asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Buttons, form borders, icons and other interface parts need at least 3:1 against what's next to them.

Color also can't be the only way you communicate something. If correct answers turn green and wrong answers turn red with no icon or text, some learners won't be able to tell them apart. Add a checkmark, an X or the words "Correct" and "Incorrect."

Use the checker below to test your course colors by entering your text and background colors to see whether they pass.

Images, Audio and Video

Alt Text

Every meaningful image needs alt text that describes its purpose in the lesson. A photo of a correctly worn harness should say what matters ("Worker wearing a full-body harness with the back D-ring between the shoulder blades"), not "Image of worker." Decorative images should be marked as decorative so screen readers skip them. Charts and diagrams need a text summary of what they show.

Captions, Transcripts and Audio Description

Prerecorded video with audio needs accurate captions, and audio-only content, like a podcast-style lesson, needs a transcript. If important information appears only visually in a video, such as a technician pointing to a valve, add narration that describes it or provide audio description. Captions should be synchronized, include speaker changes and capture meaningful sounds like alarms.

Motion and Flashing

Avoid content that flashes more than three times per second, which can trigger seizures. Give people a way to pause, stop or hide anything that moves, blinks or scrolls automatically for more than a few seconds.

Interactions and Keyboard Access

Interactions are where most courses fail, because custom drag-and-drop activities, hotspots, sliders and clickable scenes are often built for the mouse only. Here are the usual suspects and how to correct them.

Two more requirements are essential. First, focus must be visible, so that someone tabbing through the course always sees where they are. Second, the tab order should follow the visual order, so focus doesn't jump around the screen.

The Course Player, Quizzes and Documents

Your content can be perfect and still fail inside an inaccessible player. Check that the player's menu, navigation buttons, volume control and captions toggle all work with a keyboard and a screen reader. Most major authoring tools publish accessibility documentation for their players, so read it and test the specific version and settings you use.

Quizzes need clear instructions, labeled answer choices and feedback that's announced to screen readers. Error messages should say what went wrong and how to fix it.

Don't forget attachments, because a scanned PDF handout is just a picture to a screen reader. Provide tagged, accessible PDFs or, better yet, put the content directly in the course.

What About Learners on Phones and Tablets?

Mobile learners need the same access, plus a few extras, and WCAG 2.1 added criteria that matter here. Content should reflow on a narrow screen without sideways scrolling, and it shouldn't lock people into portrait or landscape unless the activity truly requires one. Anything done with a complex gesture, like a pinch or a multi-finger swipe, needs a simple tap alternative.

Make touch targets comfortably large and well spaced, especially for people with limited dexterity or anyone wearing gloves. Test on a real phone with the screen reader turned on (VoiceOver on iOS or TalkBack on Android). It feels awkward the first time, and it's the quickest way to understand what your learners experience.

Five Quick Tests You Can Run Today

You don't need a lab to find most problems. Run these on any course in under an hour.

1. Keyboard test. Unplug your mouse. Use Tab, Shift+Tab, Enter, Space and the arrow keys to complete the whole course. Can you reach and operate everything? Can you always see where focus is?
2. Screen reader test. Turn on a free screen reader such as NVDA on Windows or VoiceOver on Apple devices. Listen to a few screens. Do images make sense? Are buttons named? Is the reading order logical?
3. Zoom test. Zoom the browser to 200 percent and check that everything is still readable and usable. Then try 400 percent. Does the content reflow into a single column without sideways scrolling, and does anything overlap or disappear?
4. Contrast test. Check text, buttons and icons with the checker above or a similar tool.
5. Captions test. Watch every video with the sound off. Do the captions carry everything you need, including important sounds?

These tests won't catch everything, and nothing replaces feedback from people who use assistive technology every day. But they'll catch the problems that block the most learners, and they build habits your whole team can share.

Which Accessibility Myths Slow Teams Down?

A few beliefs keep coming up, and each one costs learners.

• "Accessible courses are boring." No. Scenarios, games and rich media can all be accessible. It just takes planning.
• "We'll add it at the end." Retrofitting a finished course costs far more than designing it right the first time.
• "An automated checker says we pass." Automated tools catch only some issues. They can't tell whether alt text is meaningful or whether a quiz makes sense by keyboard.
• "None of our learners have disabilities." You don't know that. Many disabilities are invisible, and many people choose not to disclose them at work.

How Do You Build Accessibility Into Your Process?

Retrofitting is expensive, while building accessibility in from the start is not. A few process changes make a big difference:

• Add accessibility notes to your storyboard template: alt text, captions and keyboard behavior for each screen.
• Create accessible templates and a color palette that already passes contrast.
• Choose interactions with keyboard support in mind during design, not after build.
• Include the five tests in every quality assurance (QA) round.
• Ask authoring tool and learning management system (LMS) vendors for their accessibility conformance reports before you buy.
• Publish a short accessibility statement with a way for learners to report problems.

If you work with government agencies or federal contractors, there's a legal side to this as well. This guide to Section 508 eLearning requirements explains what federal buyers expect and how it connects to WCAG.

Make Accessible eLearning Part of Every Build

Making eLearning accessible doesn't require a special team or a total rebuild. It requires real structure, readable contrast, meaningful alt text, captions, full keyboard access and a player that works with assistive technology, all checked against WCAG Level AA.

The fastest way to start is to run the five quick tests on the course you're building right now. Fix what you find, add the checks to your QA process and update your templates. Do that on every project, and accessible eLearning stops being an extra step and becomes how your team builds, so every learner gets a course that works for them.

← All articles