Accessibility is not optional, and not a bolt-on.
Two reasons. First, in most jurisdictions — including Australia under the Disability Discrimination Act — accessibility is a legal requirement for workplace training. Second, even if it weren't required, designing accessibly produces better courses for everyone. The keyboard navigation that helps a screen reader user also helps anyone using the course on a train without a mouse. Captions that serve deaf learners also serve people watching in a quiet office. Accessibility is a constraint that improves design.
The cost of bolting it on at the end is enormous.
Accessibility built into a course from day one adds maybe 10% to the build cost. Retrofitting accessibility into a finished course can double the build cost — re-recording voiceover for captions, re-coding interactions for keyboard support, rewriting alt-text against finalised images. The cheapest path is to design accessibly from the first wireframe. The second-cheapest is to never ship the course.
WCAG 2.1 AA is the working standard.
WCAG (Web Content Accessibility Guidelines) is the international standard. The three levels are A, AA, and AAA — most contracts and procurement specs target AA, which is achievable without compromising design. AAA is partial-only for most courses; aiming for it everywhere is impractical. WCAG 2.2 was published in 2023 and adds a small number of new criteria — worth being aware of, but if you're meeting 2.1 AA you're meeting roughly 95% of 2.2.
The four pillars, in plain terms.
WCAG groups requirements under four principles: Perceivable (content the learner can see or hear), Operable (controls the learner can use), Understandable (content the learner can follow), and Robust (content that works with assistive technology). When you're auditing a course, those four are the questions to ask: can they perceive it, operate it, understand it, and will their tools handle it?
Part two
The specific eLearning failures and how to avoid them.
Most eLearning accessibility issues fall into a small number of patterns. Fix these and you'll be ahead of 80% of courses on the market.
Keyboard navigation must work everywhere.
Every interactive element — buttons, links, quiz options, drag-and-drop items, hotspots — must be reachable by Tab and operable by Enter or Space. The most common failure: custom-built drag-and-drop activities that only respond to mouse. The fix: build interactions on real HTML inputs (or, in Storyline, ensure the keyboard-accessible state for each interactive layer is enabled). Test by unplugging your mouse and trying to complete the entire course with the keyboard. If you can't, neither can a screen reader user.
Focus order has to make sense.
When the learner presses Tab, focus should move through the page in reading order — top to bottom, left to right. The most common failure: a decorative element gets focus before the main content because of how it's stacked on the slide. In Storyline this is controlled via the focus order panel; in Rise it's mostly handled for you but breaks when you nest interactive elements. The test: Tab through the entire slide and check that focus lands in an order a sighted user would expect.
Every image needs alt text — or to be marked decorative.
Screen readers read every image they encounter. If the image is meaningful (a diagram, a screenshot, a chart), it needs alt text that describes what the image conveys, not what the image is. "Bar chart showing Q3 sales up 18%" beats "Bar chart of sales data." If the image is purely decorative (a stock photo for visual interest, an icon next to a text label), mark it as decorative — the screen reader will then skip it entirely, which is better than reading "image" or describing it pointlessly.
Captions for every video, transcripts for every audio.
Captions are required for video content (Success Criterion 1.2.2). Transcripts are required for audio-only content (1.2.1). Auto-generated captions are a starting point, not a finish line — they routinely mishear names, technical terms, and quiet speech. Budget for human review and correction. For voiceover-only narration, ensure a text transcript is available somewhere learners can find it; the on-screen text should not be the verbatim narration (that's a 1.2.1 fail and also tedious).
Don't carry meaning in colour alone.
Roughly 8% of men and 0.5% of women have some form of colour-blindness. A red "incorrect" and green "correct" pill conveys nothing to many of them. Always pair colour with a second cue: an icon (✗ / ✓), a word, a position, a shape change. Test by viewing the course in greyscale — if anything becomes ambiguous, the colour was doing too much work alone. See the colour theory guide for more.
Contrast ratios — the actual numbers.
Body text against its background needs a contrast ratio of at least 4.5:1. Large text (18pt+ or 14pt+ bold) drops to 3:1. UI components and meaningful graphical content need 3:1. Free tools (WebAIM contrast checker, Stark, the browser's built-in inspectors) make this instant. Test every text-on-background combination before signing off — pale-grey-on-white body text is the single most common accessibility audit failure.
Timing should be controllable.
If your course auto-advances a slide after 30 seconds, or has a timed quiz, that's a problem for anyone who reads slowly — including dyslexic learners, learners using a screen reader, or anyone reading in their second language. Either remove timing constraints (almost always the right call) or provide clear ways to extend them. Forced auto-play is a related issue: any audio or video that starts without the learner triggering it fails WCAG and most learners' patience.
No flashing, no rapid motion.
Content that flashes more than three times per second can trigger seizures in people with photosensitive epilepsy. This is rarely a problem in eLearning unless someone has made an attention-grabbing animation. Still: test any animation against the rule, and avoid rapid blink/flash effects entirely. Also: respect the operating system's "reduce motion" setting — animations should be subtler or disabled when the user has indicated they prefer less motion.
Part three
Tool-specific notes.
Different authoring tools handle accessibility differently. Quick guidance for the ones we work in.
Articulate Rise
Rise handles most of the accessibility heavy lifting automatically — proper heading hierarchy, keyboard navigation, screen reader compatibility on standard blocks. The traps are: custom embeds (which may not be accessible), the older "labelled graphic" block (older variants weren't keyboard-accessible — Rise has improved this), and any reliance on colour to communicate state. Stick to standard blocks, add alt text on every image, and you're 90% there. See the Articulate Rise guide for more.
Articulate Storyline
Storyline gives you full control, which means you can break accessibility easily. The pitfalls: custom interactive layers that don't appear in the focus order, slides with too many overlapping objects (focus order becomes chaotic), and audio without captions. Storyline's focus-order panel is the single most important accessibility tool — review it for every slide. Storyline 360 supports closed captions natively for video.
Chameleon Creator, Mindsmith, Parta, HowToo
Each handles accessibility differently. HowToo markets accessibility as a core feature and largely delivers; Chameleon and Parta have improved over time; Mindsmith is newer and varies. Whichever tool you use, the test is the same: keyboard navigation, screen reader compatibility, colour contrast, captions. Tool features don't substitute for testing the output.
Part four
A practical audit checklist.
Before signing off any course, run through this list. It catches the common failures without demanding you read WCAG end to end.
- Tab through every slide. Does focus reach every interactive element? In a sensible order?
- Complete the course with the keyboard only. Quizzes, drag-and-drop, hotspots — all of it. Where does it fail?
- Run the course with a screen reader on. macOS has VoiceOver built in; Windows has Narrator; NVDA is free. The first time is painful but tells you everything.
- Check every text-background combination. Pop the colour pair into WebAIM's contrast checker. Does it pass AA?
- View the course in greyscale. Browser dev tools can do this. Does any meaning depend on colour alone?
- Captions on every video. Reviewed and corrected, not just auto-generated.
- Alt text on every image. Or marked as decorative. No defaults like "image" or "graphic".
- Test on real assistive tech if you can. If a known user of assistive tools can review the course, do it. The gap between "passes the checker" and "actually works" is real.
Accessible eLearning is design discipline, not specialism. Build the course so the keyboard works, the screen reader works, the colours convey meaning beyond colour alone, the contrast passes, and the timing respects the learner's pace. Most of this costs nothing if you start with it in mind. None of it is glamorous — but it's the difference between a course every learner can complete and one that excludes some of them by accident.