Questions answered by this guide
- What does a screen reader actually say when it reaches an object in Storyline?
- Why does my custom hotspot just announce as "clickable"?
- How can I hear what my own Storyline course sounds like without installing NVDA?
- What's the difference between a well-labeled and poorly-labeled object?
What you'll learn
- A screen reader only announces what an object's accessible name and role actually expose, not what's visually on the slide
- A custom hotspot with no label announces as just "clickable," telling a learner nothing about what it does
- A11yCheck's Screen Reader Experience generates this exact announcement list automatically for every slide in a real scan
What's inside
Instructional designers who want to know what a screen reader actually says on their Storyline slides
- 01How screen reader announcement actually works
- 02Buttons and standard objects
- 03Custom hotspots and shapes
- 04Images and alt text
- 05Seeing this for your own course
Why it matters
It's easy to assume a slide that looks complete and clear is also clear to a screen reader user, but a screen reader only has access to an object's accessible name, role, and state, nothing about its visual design, color, or position. Hearing real examples of what that sounds like, side by side, makes the gap between "looks fine" and "sounds fine" concrete instead of abstract.
Example
A labeled vs. unlabeled hotspot
✕ Incorrect
A custom hotspot is placed over a diagram to reveal more detail on click, built from a rectangle shape with no accessible name set. NVDA announces it simply as "clickable," nothing about what clicking it does.
Storyline exposes a generic role for an interactive shape, but the actual label, what a sighted user infers from its position and cursor icon, has to be added deliberately. Without it, "clickable" is genuinely all the information a screen reader has to offer.
✓ Correct
The same hotspot has an accessible name set via the Accessibility panel: "Show detail for supply chain step 2." NVDA now announces "Show detail for supply chain step 2, clickable."
The screen reader user now knows exactly what will happen before they activate it, the same information a sighted user gets for free from the visual design.
Best practices
- Give every custom hotspot, shape, or triggered object a specific accessible name via the Accessibility panel, describing what it does, not just that it's clickable.
- Write alt text that describes what an image communicates, a screen reader announces exactly the alt text and nothing else, there's no fallback to "figure it out from context."
- Check your actual tab order against what a screen reader announces in that order, a logical visual layout doesn't guarantee a logical announcement order.
- Use A11yCheck's Screen Reader Experience to hear this for a real course without installing NVDA yourself first, then verify anything uncertain with a real screen reader per Screen Reader Testing Guide.
Common mistakes
- Assuming a visually clear slide is automatically clear to a screen reader, the two are unrelated without deliberate labeling work.
- Leaving custom hotspots and shapes with no accessible name, so they announce only their generic role.
- Writing alt text that describes an image's appearance ("chart") instead of what it communicates ("Bar chart showing a 20% increase in customer satisfaction").
How A11yCheck reviews this
A11yCheck's Screen Reader Experience feature generates an ordered list of exactly what a screen reader would announce moving through your course, for every slide in a real scan, without needing to install or run NVDA yourself first. It's the fastest way to see this gap for your own course; Screen Reader Testing Guide is the next step for confirming it yourself with a real screen reader.
Frequently asked questions
Is this the same as running NVDA myself?
It's the same underlying idea, announcements in tab order, generated automatically as part of a scan instead of requiring you to install and operate NVDA yourself. It's a fast way to see the gap; a real manual pass (Screen Reader Testing Guide) is still worth doing before publishing anything compliance-critical.
Why does a screen reader skip some objects entirely?
An object that isn't in the tab order, or is hidden from assistive technology on purpose (like a decorative shape), won't be announced at all. Sometimes that's correct, decorative content should be skipped, sometimes it means a real interactive object was never made keyboard-reachable in the first place.
Related Guides
How to Test eLearning with a Screen Reader→
A practical, no-fear guide to testing your own course with a screen reader, from your first NVDA install to knowing exactly what you're listening for.
The Complete Guide to Storyline Accessibility→
Everything instructional designers need to know to make Storyline 360 courses accessible, with a good and bad example for every check.
Storyline Triggers and Accessibility→
Storyline's trigger system, "When [event] happens on [object], do [action]," is what makes custom interactions possible, and it's also where most custom-built accessibility problems come from, since a trigger only works for the event you actually wired it to.
Alt Text Guide→
Alt text is a short written description of an image that a screen reader reads aloud in its place. Write what the image communicates, not what it looks like, and keep it under about a sentence.
Accessible Names Guide→
What an accessible name is, why "Click here" fails, and how to write clear names for buttons and controls in Storyline and Rise.
Summary
A screen reader only announces an object's accessible name, role, and state, not how it looks. Storyline's built-in objects handle this well by default; custom hotspots, shapes, and images need deliberate labeling, or they announce as little as "clickable" and nothing else.
Review your course before you publish it.
A11yCheck reviews Storyline and Rise courses for:
- Accessibility
- Course Quality
- Course Engagement
www.a11ycheck-dev.com