How to make Articulate Storyline accessible: a WCAG 2.2 AA checklist

Articulate Storyline is not accessible by default. It is accessible when you make it so, criterion by criterion, on purpose. The software gives you a focus order panel, alt text fields, closed caption support and an accessibility checker, but none of that switches itself on. A course built without deliberate accessibility work will look fine on a demo laptop and fail the moment someone tries to navigate it with a keyboard alone or a screen reader running. This checklist is the one I actually use, mapped to the specific WCAG 2.2 success criteria that matter most in eLearning, so you can check your own course against it rather than take my word for it.

Is Articulate Storyline accessible by default?

No. Out of the box, a new Storyline project has an unpredictable tab order, no alt text on any image you add, no captions on any video or audio you import, and no guarantee that your custom interactions can be operated without a mouse. Storyline's accessibility features are opt-in tools, not defaults. You have to open the Tab Order panel and set it deliberately. You have to write alt text for every image that carries meaning. You have to import or write captions yourself. The software will let you publish a completely inaccessible course without a single warning, which is exactly why a checklist matters more than good intentions.

How do you make a Storyline course keyboard accessible?

Keyboard operability is the foundation everything else sits on, because a screen reader user navigates by keyboard, and so does anyone with a motor impairment who cannot use a mouse precisely. Three things have to be true on every slide.

• Logical tab order. Open the Tab Order panel on every slide and set the sequence to match the visual and logical reading order, not the order objects happened to be added in. A tab order that jumps from a heading to a footer button and back to body text will disorient anyone using it.
• Full operability. Every button, hotspot, layer trigger and navigation control must be reachable with Tab and operable with Enter or Space. If an interaction only fires on mouse hover or mouse click, it does not exist for a keyboard user.
• A genuine keyboard test. Unplug the mouse, or just do not touch it, and go through the whole course using Tab, Shift+Tab, Enter and the arrow keys. If you cannot complete every slide this way, a learner cannot either.

This is where most Storyline courses fail first, usually because a designer built and tested with a mouse throughout and never tried the alternative.

Which WCAG 2.2 AA criteria matter most in eLearning?

WCAG 2.2 has a long list of success criteria, but in Storyline courses a smaller set does almost all the work. These are the ones I check on every project, cited by number so you can look up the exact wording yourself.

• 1.1.1 Non-text content. Every image that conveys information needs alt text. Purely decorative images should be marked as such so a screen reader skips them rather than reading a meaningless filename aloud.
• 1.2.2 Captions (prerecorded). Any video with a soundtrack needs synchronised captions, not just a transcript sitting below it.
• 1.2.3 Audio description or media alternative. Where visual information in a video is not covered by the dialogue, an audio description or a full text alternative is needed so the meaning does not depend on sight.
• 1.4.1 Use of colour. Never use colour alone to indicate a correct answer, a required field or a status change. Pair it with text, an icon or a pattern.
• 1.4.3 Contrast (minimum). Body text needs a contrast ratio of at least 4.5:1 against its background, and large text at least 3:1.
• 1.4.4 Resize text. Text must be able to scale up to 200% without losing content or functionality, which matters for anyone with low vision zooming their browser or player.
• 1.4.11 Non-text contrast. Buttons, form field borders and other interface components need at least 3:1 contrast against adjacent colours, not just the text.
• 2.4.4 Link purpose (in context). Link and button text needs to describe its destination or action on its own. "Click here" and "Next" tell a screen reader user nothing when read out of visual context.
• 2.4.7 Focus visible. Whatever object currently has keyboard focus must show a visible focus indicator, so a keyboard user always knows where they are on the slide.
• 2.4.11 Focus not obscured (minimum). New in WCAG 2.2. The focused element must not be completely hidden behind another element, such as a sticky header or a layer that pops up over it.
• 2.5.7 Dragging movements. New in WCAG 2.2. Any interaction that relies on a drag gesture, such as a drag-and-drop sorting activity, needs a single-pointer or keyboard-operable alternative that does not require dragging.
• 3.2.6 Consistent help. New in WCAG 2.2. If your course offers a help mechanism, such as a glossary link or a contact option, it needs to appear in the same relative place across slides, not move around.

None of these are exotic requirements. They are the specific, checkable things that separate a course that merely looks finished from one that a disabled learner can actually complete.

How do you test a Storyline course for accessibility?

Testing has to combine automated and manual methods, because neither one catches everything alone.

• Storyline's built-in accessibility checker. Run it before every publish. It catches missing alt text, unset tab order and some structural issues, but it cannot tell you whether your alt text is accurate or whether a caption matches the audio.
• Keyboard-only pass. Navigate every slide with Tab, Shift+Tab, Enter and arrow keys, with the mouse untouched.
• Screen reader pass. Test with NVDA on Windows, which is free, and ideally JAWS as well, since organisations still commonly deploy it. Listen for whether headings, buttons and images are announced sensibly, and whether the reading order matches the Tab Order panel.
• Colour contrast check. Check contrast against your actual published colours, not the ones in your brand guidelines, since Storyline's rendering and theme overrides can shift the final values.
• A person, not just a tool. Automated checkers verify structure. They cannot judge whether alt text is meaningful or a caption is synchronised correctly. Human review confirms the content, not just its markup, is accessible.

The checklist

This is the working list I go through before any Storyline course leaves my hands. Save it, print it, use it as your own sign-off sheet.

• Tab order set deliberately on every slide, matching the logical reading order (supports 2.4.3 and keyboard operability generally).
• Every interactive object reachable and operable by keyboard alone: buttons, hotspots, layer triggers, navigation controls.
• Alt text written for every meaningful image; decorative images marked as decorative (1.1.1).
• Captions added and synchronised for every video and audio clip with a soundtrack (1.2.2).
• An audio description or full text alternative provided where video content is not fully covered by the dialogue (1.2.3).
• Colour never used as the only way to convey meaning; status and correctness backed up with text or icons (1.4.1).
• Text contrast checked at 4.5:1 minimum for body text, 3:1 for large text (1.4.3).
• Course tested at 200% text resize or zoom with no loss of content or function (1.4.4).
• Buttons and UI component borders checked for 3:1 contrast against their background (1.4.11).
• Link and button text descriptive on its own, no "click here" or bare "Next" as the only label (2.4.4).
• Visible focus indicator present on every object as it receives keyboard focus (2.4.7).
• Focus never fully hidden behind headers, layers or other elements (2.4.11).
• Any drag-and-drop interaction has a non-drag, keyboard-operable alternative (2.5.7).
• Help or support links, where present, appear in a consistent place across every slide (3.2.6).
• Storyline's accessibility checker run and cleared before publishing.
• Full keyboard-only pass completed across every slide.
• Screen reader pass completed with NVDA, and with JAWS where the organisation uses it.

Why this matters beyond the course itself

In the UK, WCAG 2.2 AA is not a best-practice suggestion for public sector organisations, it is the legal baseline. Government guidance is explicit that the requirement extends to intranets and extranets, which is exactly where compliance and workplace training tends to sit. Building to that standard from the outset, rather than retrofitting it after a complaint or an audit, is the only approach that holds up.

I design to WCAG 2.2 AA as standard on every project, whether that is a SCORM localisation pipeline for the Chartered Institute of Procurement and Supply, safeguarding and clinical training built for NHS audiences, or care certificate training for Home Instead's regulated care staff. Accessibility is not a separate pass I run at the end. It is a set of decisions made while the course is being built, the same way I treat instructional design itself.

Frequently asked questions