Rise Continue Block Best Practices

Questions answered by this guide

• ?Does Rise's Restricted navigation cause accessibility problems?
• ?What happens if a learner can't complete a gated block?
• ?Which Rise blocks are safe to require before Continue unlocks?
• ?How do I test a gated lesson for keyboard accessibility?

What you'll learn

• Navigation gating (Restricted navigation) blocks progress until a specific interaction is completed, exactly as designed, that's also its accessibility risk
• A block that isn't fully keyboard-operable can strand a keyboard-only learner who can't complete it to unlock Continue
• Test every gated block by keyboard alone before publishing, since a mouse-based test won't reveal this failure mode

What's inside

Instructional designers building navigation-gated lessons in Rise

1. 01What navigation gating actually does
2. 02The failure mode: stranding a keyboard user
3. 03Which block types are safest to gate
4. 04Testing before you publish

Why it matters

Restricted navigation is a deliberate design choice, forcing engagement with content before moving on, and it means a learner who can't interact with the gating block by their available method has no way forward at all, not a degraded experience, a dead end. This makes testing gated blocks by keyboard non-optional, not just good practice.

When you'll encounter this

• A lesson uses Restricted navigation, requiring a block to be viewed or an interaction completed before Continue unlocks.
• The gating block is a Knowledge Check, Sorting, Categorize, or Process block rather than a simple text or media block.
• You're deciding whether to gate a lesson at all, versus leaving navigation open.

Example

Best practices

• Before gating any block with Restricted navigation, confirm that block type is fully keyboard-operable first, test it directly, don't assume.
• Prefer gating simpler, native blocks (Knowledge Check, Multiple Choice, Text) over drag-based interactions (Sorting, Categorize) where keyboard support is less reliable.
• If a drag-based interaction is important content, consider leaving it ungated (viewable but not required) rather than making it a mandatory gate.
• Test every gated lesson start to finish with the mouse unplugged before publishing, this is the one test that actually reveals whether the gate itself is a dead end.

Common mistakes

• Gating a lesson on a drag-and-drop block without testing whether it can actually be completed by keyboard alone.
• Assuming Rise's native blocks are automatically accessible in every configuration, most are, but gating changes the stakes of any gap that exists.
• Testing a gated lesson only with a mouse, which never reveals whether the gate itself can be a dead end for a keyboard user.

Practical checklist

• Every block used to gate navigation has been tested for full keyboard completion, not just keyboard reachability.
• Drag-based interactions (Sorting, Categorize) are not used as mandatory gates unless independently confirmed keyboard-operable.
• A learner who cannot complete a gated block by any available method has no scenario in the published course where they're fully blocked.
• The full gated lesson was tested start to finish with the mouse unplugged.

Frequently asked questions

Summary

Restricted navigation is a real, useful pacing tool in Rise, and it means whatever block it gates has to be fully keyboard-operable, not just present, or a keyboard-only learner can be completely stranded. Test every gated block by keyboard alone before publishing, that's the one test that reveals this specific failure mode.