How to Choose Accessible Storyline Interactions

Questions answered by this guide

• ?Which Storyline interaction is the most accessible?
• ?Is drag and drop accessible in Storyline?
• ?What's a keyboard-accessible alternative to drag and drop?
• ?Are hotspots accessible in Storyline?
• ?How do I test whether an interaction is actually accessible?

What you'll learn

• Start from the learning goal, then check what that choice requires from a keyboard and screen reader user, not the other way around
• Storyline's native drag-and-drop, matching, sequence, and ranking interactions do not currently support full keyboard access
• A simpler interaction is often the safer choice when the learning goal doesn't specifically require dragging
• Test the published output with a keyboard and a screen reader before assuming any interaction choice actually works

What's inside

Storyline developers and instructional designers choosing or reviewing interaction types for accessibility

1. 01Direct answer
2. 02Start with the learning goal
3. 03Interaction decision guide
4. 04Interaction-by-interaction accessibility considerations
5. 05When to reconsider drag and drop
6. 06Keyboard testing
7. 07Screen reader testing
8. 08Mobile considerations
9. 09Common mistakes
10. 10Practical checklist

Why it matters

The interaction you choose decides how much accessibility work you're signing up for before you build anything. Some interaction types are keyboard-operable by default in Storyline. Others have a real, currently-documented keyboard gap, not a bug you introduced by building it wrong. Choosing the interaction with the learning goal in mind, and checking what that choice requires from a keyboard and screen reader user before you build it, is cheaper than finding out during a review and rebuilding it afterward.

When you'll encounter this

• You're planning a new interaction and aren't sure which type will hold up under accessibility testing
• A drag-and-drop or matching activity failed a keyboard test and you're deciding whether to fix it or replace it
• An accessibility review flagged an interaction and you need to decide whether to rebuild it or choose something different next time
• You're building a course where accessibility is a real requirement, not an afterthought

Examples

Best practices

• Start with the learning goal, not the interaction library. Ask what the learner actually needs to demonstrate: recall a fact, apply a rule, put steps in order, explore a scenario. Several interaction types can usually satisfy the same learning goal, and they don't carry the same accessibility risk. Picking the interaction because it exists in Storyline's library, not because the learning goal requires it, is where most avoidable rework starts.
• Click-to-reveal and simple layers are generally the lowest-risk choice, and the accessibility work is almost entirely about focus, not the interaction type itself. When a click reveals a layer, states, or hidden text, the real question is whether keyboard focus moves to the new content and whether a screen reader announces that something changed. See the Layer Focus guide in the related resources for exactly how that fails and how to fix it.
• Hotspots are keyboard-reachable in current Storyline versions, which is a real, meaningful capability, not something you need to build yourself. What still needs testing: whether hover-triggered content can be dismissed with a keyboard (a documented current limitation, not an authoring mistake), and whether the hotspot's accessible name actually describes what it reveals rather than a generic label.
• Tabs are not a native Storyline object. A tabs interaction is built the same way as click-to-reveal, states and layers behind buttons, so it carries the exact same accessibility risk as any other layer-based interaction: does focus move to the newly shown tab content, and does a screen reader announce the change. Test it the same way you'd test any layer-based interaction, not as a separate category.
• Matching, sequence, ranking, and freeform drag-and-drop question types share the same current keyboard limitation as basic drag and drop. If the learning goal genuinely requires ordering or pairing items, and a click-based alternative would lose something real, look at Articulate's own accessible drag-and-drop template or a custom build using click-to-select-then-click-to-place triggers, rather than assuming a workaround doesn't exist.
• Buttons and standard multiple choice or pick-one questions are the safest default, since keyboard access works out of the box and screen readers announce them in a predictable way. One real, documented exception worth testing for: in pick-many and pick-one question slides, some screen readers re-announce the selected option instead of moving to the next one when using the down arrow. Using Tab instead of the arrow keys is the documented workaround, worth mentioning in your own course instructions if the quiz relies on arrow-key navigation.
• Sequential or multi-step interactions (a process broken into ordered steps) need the current step and total to be genuinely available to a screen reader, not just visible on screen. Articulate's own accessibility testing on step-based navigation elsewhere in their products has found real focus-order challenges specific to sequential interactions, which is exactly why this category deserves its own dedicated test pass, not just a general layer or button check.
• When two interaction types would both satisfy the learning goal, and one of them has a documented keyboard or screen reader limitation and the other doesn't, that's rarely a close call. The simpler interaction usually wins unless the learning goal specifically depends on the more complex one.

Common mistakes

• Choosing drag and drop because it looks more interactive, without checking whether the learning goal actually requires dragging.
• Assuming a hotspot's hover content is available to every learner the same way it is to a mouse user.
• Building a tabs or click-to-reveal interaction with layers and never testing whether focus actually moves to the new content.
• Treating "the mouse click works" as proof the interaction is accessible.
• Leaving keyboard testing until right before publishing, when a redesign is expensive.
• Testing only in Storyline Preview instead of the actual published course.
• Assuming a fix applied to one drag-and-drop interaction automatically fixes every drag-and-drop interaction in the course.
• Using the same interaction type for every activity in a course regardless of what each one is actually testing.
• Not stating step progress, like "Step 2 of 5," anywhere a screen reader user can actually hear it in a multi-step interaction.

Practical checklist

• Start with the learning goal, not the interaction library.
• Choose the simplest interaction that genuinely meets that goal.
• Check whether the interaction type has a documented keyboard limitation.
• If it does, decide: build a keyboard-accessible alternative, or choose a different interaction.
• Confirm focus moves to any new layer or revealed content.
• Confirm hover-triggered content has a click or keyboard equivalent.
• Test the interaction using only a keyboard, not just the mouse.
• Test the interaction with a screen reader (NVDA or VoiceOver).
• Test the published output, not just the Storyline preview.
• Re-test after any changes to the interaction.

Frequently asked questions

Summary

Choosing an accessible Storyline interaction starts with the learning goal, not a list of interaction types. Some interactions, including native drag and drop, matching, sequence, and ranking, currently have a real, documented keyboard gap. Others, like buttons, standard questions, and hotspots, are keyboard-operable by default but still need testing for the details, like focus movement and hover-dismissed content. Pick the simplest interaction that meets the goal, know what that choice requires from a keyboard and screen reader user, and test the actual published output before you call it done.