How to Handle Accessibility Testing Findings in Storyline

Questions answered by this guide

• ?What do I do when an accessibility scanner flags something in my Storyline course?
• ?How do I know if a Storyline accessibility finding is real?
• ?Can every accessibility issue be fixed inside Storyline?
• ?What Storyline accessibility issues can I fix myself?
• ?Do I need to manually test my course if it passes an automated scan?
• ?What do I do if I can't fix an accessibility finding?

What you'll learn

• Verify a finding before you change anything, automated results can be wrong or already fixed
• Not every finding is fixed the same way, some come from settings, some from design, some from Storyline's own output
• A clean scan is a starting point for manual testing, not proof a course is finished
• Document findings you genuinely cannot fix instead of guessing at unsupported changes

What's inside

Storyline developers and instructional designers who just received accessibility scan findings and aren't sure what to do next

1. 01You found a finding. What next?
2. 02Verify the finding
3. 03Identify what controls it
4. 04Fix what you control
5. 05When manual testing is needed
6. 06Retest after the fix
7. 07When you cannot fix the finding
8. 08A practical decision workflow

Why it matters

The first instinct when a scan reports a finding is to open the course and start changing things. That's usually the wrong first step. A finding is a claim about your course, not a fact you have to act on immediately. Verifying it first tells you whether it's real, whether it's already been addressed since the scan ran, and what it's actually pointing at, so the change you make is the right one instead of a guess. Skipping straight to a fix wastes time on the wrong slide, or on a setting that was never the problem.

When you'll encounter this

• An automated accessibility scan, A11yCheck or another tool, just reported findings on a Storyline course you built or inherited.
• You're not sure whether a flagged issue is something you can fix in Storyline or something outside your control.
• A finding references a WCAG criterion you don't recognize, and you're not sure what part of your course it's actually describing.
• A course passed an automated scan and you're deciding whether that's enough before publishing.

Examples

Best practices

• Reproduce the finding before changing anything. Open the exact slide it points to and confirm what it's describing. If it references a WCAG criterion you don't recognize, look it up first, don't guess at what it means.
• Work out what actually controls the issue before deciding how to fix it. It could be a Storyline authoring setting (the Player accessibility toggle, captioning), the course's design (reading order, layer structure, how an interaction was built), an individual object's configuration (accessible name, alt text, decorative flag, Tab Order), a color choice, or how a keyboard interaction was designed. Some findings trace back to Storyline's own generated output or to embedded or third-party content, and those aren't fixed the same way as a setting or an object property.
• Fix what you genuinely control directly in Storyline: accessible names, alt text, decorative flags, Tab Order, color contrast, captions, and button states. These are real, verified capabilities available in Storyline's own interface, not workarounds.
• Test manually before you trust a clean result. An automated scan cannot fully judge whether a keyboard-only pass through a slide makes sense, whether a screen reader announces layers, quizzes, and states the way you intended, or whether embedded content behaves correctly. Go through the course with a keyboard alone, and with a screen reader, for anything a scan can't fully judge.
• Retest after every fix, in this order: fix the issue, republish the course, manually retest what you changed, then run the automated scan again. A fix that looks right in the editor can behave differently once published, retesting confirms it actually worked.
• Document what you cannot fix. Some findings come from Storyline's generated HTML output or from third-party embedded content, neither of which you should hand-edit. Record what the finding is, why it can't be changed inside Storyline, and what you'd need, a player update, a different embed, a change in course design, to address it later.

Common mistakes

• Changing a slide before confirming the finding is still accurate, especially on a course that's been edited since the scan ran.
• Assuming every finding has a Storyline setting that fixes it. Some come from design decisions, not settings.
• Treating a clean automated scan as proof the course is fully accessible, instead of as a starting point for manual testing.
• Editing Storyline's generated HTML or JavaScript output directly to silence a finding. This isn't supported, and it gets overwritten the next time the course is republished.
• Skipping the republish-and-retest step, and assuming a fix made in the editor is already live in the published output.

Practical checklist

• Finding: note exactly what the scan reported and which slide or object it points to.
• Verify: reproduce the finding yourself before deciding what to change.
• Identify cause: work out whether it's a setting, a design choice, an object's configuration, or something outside Storyline.
• Fix: make the change directly in Storyline, if it's something Storyline controls.
• Manual test: check it by keyboard and, where relevant, by screen reader.
• Rescan: republish and run the automated scan again to confirm.
• Document: for anything you can't fix, record what it is and why, instead of leaving it unexplained.

Frequently asked questions

Summary

When a scanner flags something in your Storyline course, verify it before you act, work out what actually controls it, fix what's genuinely yours to fix in Storyline, test the rest by hand, and retest after republishing. Some findings come from generated output or third-party content and can't be fixed the same way, document those instead of guessing at unsupported changes.