Accessible Assessments Guide

Questions answered by this guide

• ?How do I make a Storyline or Rise quiz accessible?
• ?Are Storyline's built-in quiz slides accessible by default?
• ?Do Rise Knowledge Checks work with a keyboard?
• ?How do I create an accessible fill-in-the-blank question?
• ?Why doesn't my screen reader announce whether an answer was correct?

What you'll learn

• Multiple choice and true/false questions are the most reliably accessible question type in both tools by default
• Matching, sorting, and drag-and-drop questions need direct keyboard testing, support isn't guaranteed
• Feedback (correct/incorrect) needs to be announced to a screen reader when it appears, not just shown visually

What's inside

Instructional designers building quizzes and knowledge checks in Storyline or Rise

1. 01Which question types are safest by default
2. 02Matching, sorting, and drag-and-drop
3. 03Fill-in-the-blank and free text
4. 04Making feedback announce correctly
5. 05Testing your own assessments

Why it matters

An assessment is where a learner's understanding actually gets checked, and it's often the single most interactive moment in a course. A quiz question that can't be answered by keyboard, or whose feedback is invisible to a screen reader, doesn't just create friction, it can make it impossible for a learner to demonstrate they know the material.

When you'll encounter this

• You're building any graded or ungraded knowledge check, in either tool.
• A question uses matching, sorting, drag-and-drop, or a hotspot rather than multiple choice.
• You've built custom feedback (a layer, a triggered message) instead of using the quiz engine's built-in feedback.
• A11yCheck flags a quiz interaction as unreachable by keyboard.

Example

Best practices

• Use built-in multiple choice, true/false, or checkbox question types wherever the content allows, both tools handle keyboard access and feedback announcement for these automatically.
• For matching, sorting, or drag-and-drop questions, test keyboard completion directly before assuming it works, don't take it on faith from either tool's marketing.
• For fill-in-the-blank or free-text entry, confirm the text field itself is reachable by Tab and has a real label, not just placeholder text.
• For any custom-built feedback (not the quiz engine's native feedback), move focus to it or use an ARIA live region so a screen reader announces it the moment it appears.
• Give every answer choice, hotspot, or draggable object a real, specific accessible name, "Option A" tells a screen reader user nothing about what they're choosing.

Common mistakes

• Building custom quiz feedback with a trigger-shown layer and never testing whether a screen reader actually announces it.
• Using a drag-and-drop matching question for graded, mandatory content without confirming a keyboard path to a correct answer exists.
• Labeling answer choices generically ("Option 1," "Option 2") instead of describing what each choice actually says.

Practical checklist

• Every question can be answered start to finish using a keyboard alone.
• Correct/incorrect feedback is announced to a screen reader, not just shown visually.
• Matching, sorting, and drag-and-drop questions have been directly tested for keyboard completion, not assumed.
• Fill-in-the-blank and free-text fields are reachable by Tab and have a real, specific label.
• Every answer choice has a real accessible name describing its actual content.

Frequently asked questions

Summary

Multiple choice and true/false questions are accessible by default in both tools. Matching, sorting, drag-and-drop, and any custom-built feedback need direct testing, keyboard completion and screen reader announcement aren't guaranteed just because the question displays correctly.