StoryAudit

← Back to storyaudit.app

How to check a Storyline course for accessibility gaps before an audit

What an automated check of the .story file can verify, what it cannot, and how to get the list of gaps out of a course in minutes.

What to check

What a file check can and cannot verify

The .story file records alt text, captions, slide titles and player settings, so a tool that reads the file can report coverage for those precisely: which images have alt text, which audio has captions, which titles are blank or duplicated, which controls are on. It cannot judge whether the alt text is any good, and it cannot test what only exists at runtime: contrast, focus order, keyboard traps and video captions still need a person with a screen reader and the published output.

StoryAudit's Health Check is explicit about that line and stays on the file side of it. It gives you the coverage list so the person with the screen reader spends their time on judgment instead of counting.

The manual way

Open every slide in Storyline, open the accessibility settings on every object, note what is missing, repeat for every layer. For a 60-slide course that is several hundred dialogs. It also needs a Storyline seat, which the person doing the audit often does not have.

Do it in StoryAudit

Drop the .story file into Health Check. No Storyline license needed, and the file never leaves your browser.

See the accessibility section on the bundled sample course. No sign-up.

Open the live demo →

Across versions and libraries

Compare shows an “Accessibility changed” banner between two versions, with the before and after alt text and captions, so a fix can be verified without re-auditing the whole course. Batch Check runs the accessibility coverage check across a folder and flags every course that fails a policy rule you set once.

↑ Back to top