Make sure that all of the content in your eLearning resource can be controlled with a keyboard, and not with a mouse.
How do I comply?
- Make sure that the learner can navigate through and operate your eLearning resource using only a keyboard.
- Rapid authoring tool providers should tell you which of their interactive activities are accessible and which are inaccessible for keyboard only users.
- The following interactions are normally inaccessible for keyboard only users:
- Drag and drop.
- Word bank.
- Matching drag and drop.
- Sequence drag and drop.
- The following interactions are normally accessible for keyboard only users:
- Pick one.
- Pick many.
- Text entry.
- Shortcut key.
- Multiple choice.
- Multiple response.
- Matching drop-down.
- Sequence drop-down.
- Numeric activities.
There are some activities which are exempt because they cannot be carried out by a keyboard, but they are unlikely to apply to eLearning resources. These depend on the path of the user’s movement, e.g. a handwriting tool or a free hand drawing tool.
- People with a motor impairment who cannot use a mouse, will use a keyboard to access your eLearning resource. They may use standard keys like the tab, enter, space and arrow keys on the keyboard to navigate through your content. They may also use a screen reader which also operates via the keyboard.
- Remember that the keyboard, could be an alternative assistive keyboard or a keyboard “emulator” e.g. speech input, switch devices or sip and puff software.
- Users who are blind or have low vision, who cannot see the mouse pointer on the screen, also use a screen reader and keyboard to interact with your eLearning resource.
Many eLearning designers assume that keyboard accessibility will limit the interactivity of their eLearning resources. But our experience is that this is not the case. Your authoring tool provider, may automatically provide you with alternative accessible activities for any mouse only interactions e.g. CourseArc. If they do not, it may be possible to create accessible versions of mouse only interactions by thinking creatively. We have given some examples of keyboard accessible interactions that we have created using Storyline below, but would love to hear from you if you have any other examples, using any other authoring tool.
1. Hotspot interactions
CourseArc automatically adds an accessible transcript for hotspot interactions.
Transcript automatically created for hotspot interaction
2. Drag and drop matching interactions
CourseArc automatically adds an accessible alternative for matching drag and drop interactions.
Multiple choice interaction automatically created as the accessible alternative for a drag and drop matching interaction
3. Drag and drop interactions
If your authoring tool does not automatically create accessible alternatives, try designing your own. Remember that some learners use a keyboard instead of a mouse due to a motor, not a visual impairment, which means that they will be able to see the interaction. For this reason, the example we have given, uses motion path animation to introduce interactivity which is controlled by the keyboard rather than the mouse.
Accessible drag and drop game
A quiz designed to help learners find out how to use the correct recycling bins. The video first shows the quiz designed for mouse users, which uses a drag and drop interaction. The learner drags each item to the correct bin.
The video then shows a manually designed keyboard accessible drag and drop interaction. In this version of the quiz, the learner selects each item from a multiple option list. When they select the item, a tick appears in the box next to the item and it moves on a motion path into the recycling bin. If they make a mistake, they can select the option again. This removes the tick in the box, and it then moves the item out of the recycling bin.
4. Quiz questions
Your authoring tool provider should tell you which of the quiz question types available are accessible for keyboard only users. If they don’t, you can test this yourself by trying to navigate through them using your keyboard. It’s also a good idea to check quiz slides with screen readers as we have found some bugs with different screen readers and browsers.
A learner using a keyboard to successfully complete a final knowledge check in an eLearning resource. The learner is able to use the keyboard to navigate through a variety of quiz question formats including a multiple option, true or false and a text entry question. The eLearning resource also includes a drag and drop example which has been manually created. This interaction allows the learner to tab through a series of definitions in order to match it with a correct role. When the learner selects their preferred definition by using the space bar, the option they have selected follows an animation path, which moves it to sit above the role they are trying to match.
A drag and drop interaction about inclusive webinars and some of the accessibility issues to be aware of. The interaction has been made accessible so that the learner can select 1 of a series of 8 quotes using the space bar. They then tab through the four answer option boxes. When they reach the correct answer box, they select this answer box by using the space bar, and the quote automatically appears in the selected box. The learner returns to the next quote using the shift and tab keys and repeats the process until all 8 quotes are in the correct boxes. When they have completed all 8 quotes, they then tab to the Check Answers options which tells them if their answers are correct.
How can I test?
- Use only the keyboard to navigate and carry out all of the activities in your eLearning resource. Use the testing table in the WebAIM – Keyboard accessibility article to find out the most common keyboard interactions to test keyboard accessibility.
- Some tools, e.g. Lectora, have an accessibility checker, if you select the Use Web Accessibility Settings option for your title. The accessibility checker will identify any objects which are not accessible for keyboard users. It will label them as not 508 compliant which are US accessibility regulations.
- WebAIM: Keyboard accessibility article
Good overview, although the focus is more on web development. Has useful information about testing with a keyboard.
- Web Accessibility Initiative: Keyboard compatibility information
Short video, and further information about keyboard accessibility.
Make all functionality available from keyboard.
|WCAG link||2.1.1 Keyboard (Level A)|
|WCAG text||All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints.|
Copyright © 2019 W3C ®
Please help us to make this page better for everyone in the eLearning community by contacting us with your improvements, examples and suggestions.