Questions answered by this guide
- What does a screen reader actually announce in a Rise lesson?
- Are Rise's native blocks accessible to screen readers by default?
- Why does my Embed block sound broken to a screen reader when the rest of the lesson doesn't?
- How can I hear what my own Rise lesson sounds like without installing NVDA?
What you'll learn
- Rise's native blocks (Text, Button, Labeled Graphic, Knowledge Check) generally announce correctly without extra work
- Embed blocks carry whatever HTML you put in them, including its accessibility gaps, Rise can't fix what it doesn't control
- A11yCheck's Screen Reader Experience generates a real announcement list for every lesson in a scan
What's inside
Instructional designers who want to know what a screen reader actually says in their Rise lessons
- 01Why Rise's native blocks announce well by default
- 02Where Embed blocks break the pattern
- 03Labeled Graphic and interactive blocks
- 04Seeing this for your own lesson
Why it matters
Rise's block-based design means most of a lesson inherits good screen reader behavior for free, structure, headings, and native interactive elements are handled by Rise itself. That's real, and it also means the one place accessibility work still falls entirely on the course author, custom embedded content, is easy to overlook precisely because everything else just works.
Example
A native block vs. an Embed block
✕ Incorrect
A lesson uses an Embed block to add a custom interactive diagram from a third-party tool. The embedded HTML has no accessible names on its own controls. A screen reader announces the surrounding Rise lesson correctly, then goes silent or announces "clickable" repeatedly once it reaches the embedded content.
Rise renders the Embed block's HTML exactly as provided, it has no way to add accessibility information to code it doesn't control. Whatever gaps exist in the embedded source carry straight through.
✓ Correct
The same content is rebuilt using Rise's native Labeled Graphic block instead, or the third-party embed is confirmed accessible (real accessible names, keyboard support) before it's used.
A native Rise block gets Rise's own accessibility handling for free. An embed only gets what was actually built into the embedded source, which has to be verified, not assumed.
Best practices
- Prefer native Rise blocks over an Embed block wherever the content allows, you inherit Rise's own accessibility handling automatically.
- Before using an Embed block, check the embedded source's own accessibility directly, Rise can't add what isn't already there.
- For Labeled Graphic markers and other interactive native blocks, still confirm each marker's label is specific and descriptive, not just "Marker 1."
- Use A11yCheck's Screen Reader Experience to hear a real lesson's announcement order without installing NVDA first, this is usually the fastest way to spot exactly where an Embed block breaks the pattern.
Common mistakes
- Assuming an Embed block inherits Rise's accessibility handling the way native blocks do, it doesn't, it's independent HTML.
- Using a third-party embedded widget without checking whether its own controls have real accessible names.
- Labeling Labeled Graphic markers generically instead of describing what each one actually reveals.
How A11yCheck reviews this
A11yCheck's Screen Reader Experience feature generates an ordered announcement list for every lesson in a real scan, the fastest way to hear exactly where a lesson, most often an Embed block, stops announcing correctly. Screen Reader Testing Guide is the next step for confirming it yourself with a real screen reader.
Frequently asked questions
Why do my native Rise blocks sound fine but my Embed block doesn't?
Native blocks get Rise's own accessibility handling automatically. An Embed block is independent HTML Rise has no control over, whatever accessibility work exists in the embedded source is all it has.
Can I make a third-party embed accessible if it wasn't built that way?
Only if you control or can modify the embedded source. If it's a fixed third-party widget, the more reliable path is usually rebuilding the same content with native Rise blocks instead.
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 Rise 360 Accessibility→
Everything instructional designers need to know to make Rise 360 courses accessible, written for Rise specifically, not adapted from Storyline.
Rise Continue Block Best Practices→
Rise can require a learner to view or complete a block before the lesson lets them continue. This is a real, useful pacing tool, and it also has a real accessibility failure mode: a learner who can't interact with a block the way Rise expects gets stuck with no way to proceed.
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
Rise's native blocks announce correctly to a screen reader by default, that's a real strength of building in Rise. The gap consistently shows up in Embed blocks, which carry only whatever accessibility work already exists in their embedded HTML, and nothing Rise adds automatically.
Review your course before you publish it.
A11yCheck reviews Storyline and Rise courses for:
- Accessibility
- Course Quality
- Course Engagement
www.a11ycheck-dev.com