Understanding Success Criterion 2.1.4: Character Key Shortcuts

Success Criterion 2.1.4 Character Key Shortcuts (Level A): If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

Turn off
A mechanism is available to turn the shortcut off;
Remap
A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc);
Active only on focus
The keyboard shortcut for a user interface component is only active when that component has focus.

Intent

Character key shortcuts work well for many keyboard users, but are inappropriate and frustrating for speech input users — whose means of input is strings of letters — and for keyboard users who are prone to accidentally hitting keys. As a result, users must be able to turn off or reconfigure shortcuts made up of a single character key, or two or more successive character keys.

This success criterion is becoming increasingly important in the mobile realm as growing number of apps more fully enable keyboard controls.

Note that this success criterion doesn’t affect components such as listboxes and drop-down menus that contain words that may be selected by one or more character keys, since the shortcuts are only active when the components have focus. Similarly, components such as menus may be accessed or opened with an initial, non-single character shortcut (e.g., “ALT” or “ALT+F”). This makes the full path to invoking a menu a two-step shortcut that includes a non-printable key.

Note that Accesskeys are not affected because they include modifier keys.

Speech Input users generally work in a single mode where they can use a mix of dictation and speech commands. This works well because the user knows to pause before and after commands, and commands are usually at least two words long. So, for instance, a user might say a bit of dictation, such as "the small boat", then pause, and say a command to delete that dictation, such as "Delete Line". In contrast, if the user were to say the two phrases together without a pause, the whole phrase would come out as dictation (i.e., "the small boat delete line"). Although speech input programs often include modes that listen only for dictation or only for commands, most speech users use the all-encompassing mode all the time because it is a much more efficient workflow. It could increase command inefficiency by 300% if users were to change to command mode and back before and after issuing a command.

Speech users can also speak most keyboard commands (e.g., "press Control Foxtrot") without any problems. If the website or app is keyboard enabled, the speech user can also write a native speech macro that calls the keyboard command, such as "This Print" to carry out Ctrl+P.

Single-key shortcuts are the exception. While using single letter keys as controls might be appropriate and efficient for many keyboard users, single-key shortcuts are disastrous for speech users. The reason for this is that when only a single key is used to trip a command, a spoken word can become a barrage of single-key commands if the cursor focus happens to be in the wrong place.

For example, if the cursor focus is in the main window of a web mail application that uses common keyboard shortcuts to navigate ("k"), archive ("y") and mute messages ("m"), and someone enters an office and says "Hey Kim" and the speech user's microphone picks that up, "y" archives the current message. "k" moves down one conversation and "m" mutes a message or thread. Or, if the speech user looks up and says "Hey Mike" without remembering to turn off the microphone, the same three things happen in a different sequence. A user interacting with a webpage or web app that doesn't use single-character shortcuts doesn't have this problem. A speech user filling in a text input form may find that a phrase that is accidentally picked up by the speech microphone results in stray text being entered into the field, but that is easily seen and undone. To see a video of these types of issues, go to the Resources section of this page.

Benefits

Examples

Example 1: Disable Shortcuts

A mechanism is provided to allow users to disable character-key shortcuts. The character key shortcuts are not the only way to carry out these commands. A speech user disables the shortcuts and can prevent words that are picked up by the microphone from triggering single-key shortcuts.

Example 2: Alternate Control

A mechanism is provided to allow users to change character-key shortcuts

A keyboard-only user is in a long issues thread. While reading the thread she accidentally hits the “s” key, which moves focus to the search bar at the top of the document. This causes her to lose her place and her train of thought. She changes the shortcut to include another key so she can avoid future interruptions.

Example 3: Shared Alternate Control

A mechanism is provided to allow users to change character-key shortcuts in such a way that the changes can be saved and shared with other users.

Related Resources

Resources are for information purposes only, no endorsement implied.

Web apps that use character-key shortcuts and allow users to disable and/or change these shortcuts:

Videos of speech user trouble with single character key shortcuts:

Techniques

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.

Sufficient Techniques

  • Users have a way to turn off single-key shortcuts
  • A mechanism is provided to allow users to change character-key shortcuts. The remapping mechanism includes non-printing characters. The alternative shortcuts could be longer strings of up to 25 characters that would directly serve as native speech commands for any speech engine.

Advisory Techniques

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

Failures

The following are common mistakes that are considered failures of this Success Criterion by the WCAG Working Group.

  • Failure of Success Criteria 2.1.4 due to a webpage or web app that includes single-key shortcuts not including a control that allows users to turn the shortcuts off or a control that allows users to change the shortcuts to key combinations that include keys that are not upper or lower-case letters, punctuation, number, or symbol characters.

Key Terms

keyboard shortcut

New

alternative means of triggering an action by the pressing of one or more keys

mechanism

process or technique for achieving a result

Note

The mechanism may be explicitly provided in the content, or may be relied upon to be provided by either the platform or by user agents, including assistive technologies.

Note

The mechanism needs to meet all success criteria for the conformance level claimed.

user interface component

a part of the content that is perceived by users as a single control for a distinct function

Note

Multiple user interface components may be implemented as a single programmatic element. Components here is not tied to programming techniques, but rather to what the user perceives as separate controls.

Note

User interface components include form elements and links as well as components generated by scripts.

Note

What is meant by "component" or "user interface component" here is also sometimes called "user interface element".

An applet has a "control" that can be used to move through content by line or page or random access. Since each of these would need to have a name and be settable independently, they would each be a "user interface component."