Articulate Storyline’s built-in Accessibility Checker is a fantastic tool. If you’re creating accessible e-learning, you should absolutely use it.
But it’s important to remember what Storyline itself tells you: it’s a starting point.
Passing the accessibility checker doesn’t necessarily mean your course is accessible or provides a good experience for learners using screen readers or keyboard navigation. In fact, I’ve seen projects that report “0 issues found” while still containing several significant accessibility problems.
Here are five important things you should check manually that Storyline’s Accessibility Checker won’t catch.
1. Color Contrast Problems
One of the biggest surprises is that the Accessibility Checker does not verify whether your colors meet WCAG 2.1 contrast requirements.
For example, a project can receive a perfect accessibility score while displaying white text on a semi-transparent white background, which is something that’s very difficult to read.
The same applies to buttons. In one example I tested, only three of six colored buttons met contrast requirements, and even those only passed because the text was large enough to qualify under the WCAG standards for large text. The remaining buttons failed the contrast guidelines entirely.
The checker also won’t warn you if a busy background image makes your text difficult to read.
Always verify color contrast yourself using a contrast checker or other accessibility testing tool.
2. Logical Focus Order
Another major omission is keyboard focus order.
Someone using a screen reader, or anyone who prefers keyboard navigation, moves through your Storyline course using the Tab key (and arrow keys for reading). If the focus order jumps randomly around the screen, navigating the course becomes frustrating and increases cognitive load.
For example, imagine a menu arranged in a circle. Most learners would naturally expect keyboard focus to move clockwise or perhaps from top to bottom and left to right. Instead, the tab order might jump unpredictably from one button to another.
Technically everything is accessible, but the experience isn’t intuitive.
Fortunately, Storyline lets you edit the focus order manually:
- Open the Focus Order window.
- Select each object to see its location on the slide.
- Drag items into a logical reading order (may need to choose “custom” reading order).
- Save your changes.
Focus order becomes even more important, and more complicated, when your slides include multiple layers, since every layer appears within the same Focus Order window.
The Accessibility Checker won’t tell you if your focus order is confusing. That’s something only you can evaluate.
3. Bad Alt Text
The Accessibility Checker verifies that objects have alternative text, but it doesn’t evaluate whether that text is actually useful.
Storyline’s AI-generated alt text can be especially problematic.
For example, I created an invisible hotspot over a “Go Back” button. Storyline automatically generated this description:
“A green rectangular border with a black outline enclosing a green solid colored interior.”
Technically, the object has alt text, so the Accessibility Checker is satisfied.
But when a screen reader user tabs to that invisible hotspot, hearing that description provides absolutely no useful information.
A much better alt text would simply be:
“Go back.”
Always review automatically generated alt text and ask yourself one question:
Would this help someone understand what this object actually does?
If the answer is no, rewrite it.
4. Broken Buttons and Triggers
The Accessibility Checker also doesn’t know whether your interactive elements actually work.
For example:
- Next buttons that don’t navigate anywhere
- Broken triggers
- Hotspots that no longer function
- Buttons linked to deleted slides
A keyboard or screen reader user can still tab to these objects and activate them, but nothing happens.
Think of it like a broken hyperlink on a website. It’s still there, but it’s useless.
Testing every interaction manually is still an essential part of accessibility testing.
5. Heading Structure
Storyline encourages you to use headings, and the Accessibility Checker reminds you to add them.
But it doesn’t tell you whether you’re using headings appropriately.
Headings exist to organize content. In long documents or web pages, screen reader users often jump between headings using keyboard shortcuts to quickly find the section they need.
Many Storyline slides simply don’t contain enough text to benefit from multiple heading levels.
For example, imagine a slide titled Ethics.
A screen reader may announce:
- The slide title (“Ethics”)
(It’ll actually read the slide title twice) - Heading 1: Ethics
- Heading 2: Summary of Ethics
- Then the body text
That’s a lot of extra announcements before the learner reaches the actual content.
If your headings aren’t adding meaningful structure, they may simply create additional listening time without improving navigation.
Use headings thoughtfully, not just because the Accessibility Checker recommends them.
Bonus: Accessibility Controls Aren’t Always Necessary
Here’s one bonus tip that surprises many Storyline developers.
The Accessibility Checker almost always recommends enabling the Play/Pause and Playback Speed controls.
Those controls absolutely belong in courses that include:
- Video
- Audio
- Timed animations
- Timeline-controlled interactions
But what if your course doesn’t use any of those?
If every object appears immediately when the slide loads, the play and playback speed controls don’t actually do anything useful. Instead, they become extra keyboard stops on every single slide.
For someone navigating with the keyboard, every slide forces a journey through every button:
- Play
- Playback Speed
- Settings
- Previous
- Next
Those extra controls cannot be removed from the player’s keyboard navigation order once they’re enabled.
In a simple click-through course, they simply add unnecessary tab stops and make navigation slower.
So while the Accessibility Checker may recommend enabling these controls, think about whether they actually improve the learner’s experience before turning them on.
The Bottom Line
Storyline’s Accessibility Checker is an excellent first step, but it’s not a substitute for accessibility testing.
Many accessibility issues require human judgment. Others can only be found by actually navigating your course the way your learners will.
If you’re serious about building accessible e-learning, try using a screen reader yourself.
If you’re on Windows, NVDA is free and widely used. Spend just a few minutes navigating one of your own Storyline courses with only your keyboard and a screen reader.
You may be surprised by what you discover! And you’ll almost certainly build better courses because of it.