Spotlight 34

Keyboard accessibility

(WCAG 2.1.1, 2.1.2, 2.1.3, 2.1.4)

Not all learners navigate content using a mouse. In this spotlight let’s review how we can make content accessible to keyboard users.

2.1.1 Keyboard (Level A) and 2.1.3 Keyboard (No Exception, Level AAA) are similar in that they require that any functionality of your content should be available through a keyboard. Learners should be able to move through the content, access different sections, and interact with buttons and links using only the keyboard. Equally, all interactive elements such as quizzes or simulations should be designed to work with keyboard input. In addition, there should be no time constraints to pressing the keys. 

The difference between the two criteria is that the lower level guideline allows exceptions when the underlying function depends on the movement of the cursor such as drawing an image or following an on-screen pattern in a game.

When it comes to authoring tools, you should check your tool's Voluntary Product Accessibility Template (VPAT) to see which interactions are supportive of keyboard users. For example, in Storyline 360, drag-and-drop activities are not fully accessible with a keyboard only. In Rise 360, currently charts, carousels, process blocks, and sorting activities are also problematic for keyboard users. If you want to use such interactions, it's best practice to offer an alternative option such as multiple-choice or drop-down activities. 

Next, let's look at keyboard shortcuts. Like many of us, users of assistive technology use shortcuts to navigate through the content quickly. Besides, many authoring tools have built-in keyboard shortcuts that learners can use. For example, in Storyline 360, the Ctrl + Alt + M combination mutes and unmutes audio. The problem is if the shortcut used by the assistive technology is the same as the shortcut used by the tool you're using. Many tools, including Storyline 360 for example, avoid that, so there's nothing to worry about. However, if your authoring tool allows you to create custom shortcuts for specific functions, you need to make sure to comply with 2.1.4 Character Key Shortcuts (Level A)

This guideline is a bit technical. The easiest way for learning content creators to comply is to avoid using single-character shortcuts (like letters, numbers, or punctuation alone) and instead use a combination of keys that are not used by assistive technologies. Shortcuts for assistive devices are usually available on the product website.

Finally, we want to mention 2.1.2: No Keyboard Trap (Level A) that we covered in Spotlight 10. According to this criterion, keyboard-only users should be able to enter, interact and exit the content that receives focus using only the standard keyboard keys such as Shift and Tab, Tab, or the Arrow keys. A keyboard trap occurs when learners can navigate to an item, but then cannot move away from it. If the user needs to use non-standard keys to exit the content, then those instructions must be provided to the learner to avoid keyboard trap. 

Because the way interactive elements work is determined by the authoring tool, it’s unusual to come across a keyboard trap in eLearning. However, it's always advisable to test your content with the authoring tool to ensure there are no traps. It’s also possible to inadvertently create a trap for learners through certain design choices, such as a navigation button that disappears or a drag-and-drop activity that is required to be completed to move ahead in the training.     


Discussion questions:

Get Involved: Come to the LCA Spotlight LinkedIn group and join the conversation.

When you post in the community, use the hashtag #LCASpotlightKeyboard

Spotlight 33: Adaptability

Coming soon

Spotlight 35: TBC