Accessibility FundamentalsGuide

Keyboard Navigation Guide

Keyboard navigation means every interactive object in your course, buttons, links, quiz answers, layers, can be reached and used with Tab, Shift+Tab, Enter, and arrow keys alone, with no mouse required.

Reading time
~7 min
Difficulty
All levels
Resource type
Guide
Last updated
2026-08-07

Questions answered by this guide

  • What is keyboard navigation?
  • Why does my keyboard jump around or get stuck on a slide?
  • How do I test if my course works without a mouse?
  • What is a keyboard trap?
  • Which WCAG criterion covers keyboard access?
  • Are Storyline's quiz slides keyboard accessible by default?

What you'll learn

  • Some learners cannot use a mouse at all
  • Test your course using only Tab, Shift+Tab, Enter, and arrow keys
  • Every interactive object needs to be reachable, visible, and usable this way

What's inside

Instructional designers reviewing keyboard access in any authoring tool

  1. 01The concept
  2. 02Why keyboard access matters
  3. 03What WCAG requires
  4. 04How to test it
  5. 05Common mistakes that break it

Why it matters

Some learners cannot use a mouse at all. This includes people with motor disabilities, people using screen readers, and anyone using assistive technology like a switch device. If your course only works by clicking with a mouse, these learners are locked out. This is WCAG success criterion 2.1.1 (Keyboard, Level A): all functionality must be operable through a keyboard, with no requirement to make specific mouse-only movements or exact timings. A closely related criterion, 2.1.2 (No Keyboard Trap, Level A), adds a second requirement that's easy to miss: it is not enough to let a learner move focus into something like a layer or popup, they must also be able to move focus back out of it using only the keyboard.

When you'll encounter this

  • Your course has a custom-built interaction, drag-and-drop, hotspots, freeform clicking, that wasn't built with Storyline's or Rise's native interactive objects.
  • A layer, lightbox, or popup opens over the base layer and needs its own way to close.
  • You're reviewing a course someone else built and don't know whether it was ever tested without a mouse.
  • A11yCheck flags a keyboard navigation issue on a scan report.

Examples

Custom drag-and-drop interaction

✕ Incorrect

A matching question is built with freeform drag-and-drop objects, triggered only by mouse drag. Tab skips over them entirely.

Dragging requires precise mouse movement with no keyboard equivalent, and the objects were never added to the tab order, so a keyboard-only learner can't select or place an answer at all, not just find it harder.

✓ Correct

Rebuild the question as a click-based "select the matching pair" interaction using Storyline's built-in button states, so each item and each target is a real button reachable by Tab and activated with Enter or Space.

Buttons are natively part of Storyline's tab order and support keyboard activation, so the interaction satisfies WCAG 2.1.1 without needing exact mouse-drag precision to answer correctly.

Layer that traps keyboard focus

✕ Incorrect

A layer opens with extra instructions. It closes only via a small X icon built as an image with a mouse-click trigger, no keyboard trigger.

Once focus enters the layer, a keyboard-only learner has no way to activate the close control and no way to Tab back to the base layer, a genuine keyboard trap under WCAG 2.1.2.

✓ Correct

Rebuild the close icon as a real Storyline button object instead of an image with a click trigger, so it's automatically in the tab order and can be activated with Enter or Space.

Now a keyboard-only learner can Tab to the close button and press Enter to exit the layer, satisfying WCAG 2.1.2's requirement that focus can always move back out.

Best practices

  • Test your course by pressing Tab instead of clicking. If you cannot reach something with Tab, a keyboard-only learner cannot either.
  • Make sure every button, link, and interactive object can be reached in a sensible order.
  • Make sure whatever is currently focused is visible on screen, with a visible outline or highlight.
  • Avoid keyboard traps, places where Tab gets stuck and cannot move forward or backward. This is its own WCAG requirement (2.1.2), separate from basic reachability.

Common mistakes

  • Custom hotspots and drag-and-drop objects that only respond to a mouse click.
  • A visible focus outline that has been styled away or hidden.
  • Tab order that jumps around the slide in a confusing way.
  • A layer or popup that opens but cannot be closed with the keyboard.

Practical checklist

  • You can reach every button, link, and interactive object using only Tab and Shift+Tab.
  • You can activate anything you reach using Enter or the Space bar.
  • You can always see where keyboard focus currently is.
  • Nothing traps keyboard focus so you cannot Tab away from it.
  • Tab order follows a sensible, predictable path through the slide.

How A11yCheck reviews this

A11yCheck's scan checks whether interactive elements are reachable in the keyboard tab order and whether focus is visibly indicated. It cannot click and drag through every custom interaction the way a human tester can, so a manual Tab-through, especially of custom drag-and-drop and layers, is still worth doing for anything the scan flags or anything custom-built.

Frequently asked questions

What is keyboard navigation?

Using Tab, Shift+Tab, Enter, and arrow keys to move through and use a course, without touching a mouse.

Who actually uses a keyboard instead of a mouse?

People with motor disabilities, people using screen readers, and anyone using assistive technology like a switch device or eye-tracking system.

How do I test this myself?

Put your mouse aside. Press Tab through the slide and try to reach and activate everything using only the keyboard. See the Keyboard Navigation Cheat Sheet for the exact keys to use.

What is a keyboard trap?

A place where Tab gets stuck. You can move focus into something, like a popup, but you cannot Tab back out of it. This traps a keyboard-only user, and it's covered by its own WCAG requirement, 2.1.2.

Are Storyline's built-in quiz slides keyboard accessible?

Yes, by default. Custom-built interactions are not automatic. Test them the same way you would test any other slide.

Does Storyline or Rise support skip links, so a keyboard user can bypass repeated navigation?

Neither tool exposes a skip-link setting the way a hand-coded website would. In practice this matters far less in eLearning than on a website with a large repeated navigation menu, a course's per-slide interactive elements are usually few enough that Tab order alone doesn't become a burden. If a specific slide has an unusually large number of repeated controls, the more useful fix is trimming or restructuring the slide itself rather than looking for a skip-link setting that isn't there.

Related Guides

Summary

A course that only works with a mouse locks out learners who use a keyboard or assistive technology. Test with Tab alone, and make sure everything can be reached, seen, activated, and exited. This is WCAG 2.1.1 and 2.1.2.

Review your course before you publish it.

A11yCheck reviews Storyline and Rise courses for:

  • Accessibility
  • Course Quality
  • Course Engagement
Start a free review →

www.a11ycheck-dev.com