Understanding SC 2.1.4 Character Key Shortcuts (Level A)

In Brief

Goal: Reduce accidental activation of keyboard shortcuts.
What to do: Ensure character-only shortcut keys can be turned off or modified.
Why it's important: Character-key shortcuts are easy to accidentally trigger, especially for keyboard and some speech input users.

Success Criterion (SC)

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 include one or more non-printable keyboard keys (e.g., Ctrl, Alt);
Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.

Intent

The intent of this success criterion is to reduce accidental activation of keyboard shortcuts. Character key shortcuts work well for many keyboard users. However, particularly if the shortcuts are mapped to single printable characters, keyboard users may trigger them accidentally. These shortcuts can also be problematic for certain voice control/speech recognition users, as some of the software used by this user group converts any speech into simulated key presses, which can lead to unintended activations. To rectify this issue, authors need to allow users to turn off or reconfigure shortcuts that are mapped to single character keys.

Note

Even though this success criterion refers to character keys, note that it's not relevant whether a shortcut can be activated using a single physical key on a keyboard, or if it requires a combination of keys to be pressed. For instance, on most full-size US and UK keyboard, the ? (question mark) symbol is accessed using Shift+/ (forward slash key next to the right-hand Shift key). On a UK keyboard, in Windows, the é (lowercase "e" with an acute accent) requires the use of AltGr+e. The specific key combination required for certain characters will also vary depending on the user's keyboard layout. However, shortcuts that use these characters still fall under the requirements of this success criterion. What matters is that a shortcut relies on a printable character (letters, punctuation, numbers, symbol characters), and not the number of physical keyboard keys that users need to press to trigger it.

Note

The success criterion also applies to situations where a shortcut is based on a sequence of character keys – for example, pressing G and then A in quick succession to trigger an action. While the individual character key presses don't immediately trigger the action, overall these types of shortcuts still rely on a series of character keys.

This success criterion doesn't affect components such as listboxes and drop-down menus. Although these components contain values (words) that may be selected by one or more character keys, the shortcuts are only active when the components have focus. Other components such as menus may be accessed or opened with a single non-character shortcut (e.g., Alt or Alt+F) before pressing a single character key to select an item. This makes the full path to invoking a menu a two-step shortcut that includes a non-printable key. Access keys are also not affected because they are generally (depending on the user agent) activated using modifier keys.

Background on the mechanics of speech input

Speech input users generally work in a single mode where they can use a mix of dictation and speech commands. 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 ("the small boat delete line").

In most cases, voice control/speech recognition software is "context-aware" – speech is not interpreted as dictation, unless focus is on a form control or field that accepts keyboard input. Otherwise, speech is only interpreted as a command. In addition, even when focus is inside a form control or field that accepts keyboard input, dictation does not generate synthetic key presses – the spoken text is generally injected directly into the relevant form control/field. Synthetic key presses only happen when a user gives an explicit command, such as "Press X key".

However, there are some voice control/speech recognition programs (such as Talon Voice) that are not "context-aware". All speech is interpreted as either a command or dictation, regardless of where the current focus is. In addition, saying certain keywords is interpreted by some programs as a shorthand for the "Press … key" command, leading to potential unintentional single key presses. Lastly, while uncommon, programs that are not "context-aware" may also turn dictation into synthetic key presses, meaning that an unintentionally spoken word can become a sequence of single-key commands if the cursor focus happens to be in the wrong place. Character key shortcuts will be problematic for users of these non-context-aware programs.

Keyboard use with screen readers

The behavior of screen readers when it comes to keyboard interactions, and whether or not key presses are passed on to web content, varies depending on the specific platform and screen reader in use.

On Windows, screen readers (such as Jaws, NVDA, and Narrator) generally operate in two different modes: browse mode and focus mode.

In browse mode, screen readers intercept all key presses, as many of their commands are bound to single key shortcuts. Key presses are then only passed on to web content depending on the context. For instance, if focus is on a button element, only Space and Enter key presses (and a few generic keys, such as Tab) will be passed to the web content – any other key presses will be "swallowed" by the screen reader. This behavior is overridden in HTML when elements have a role="application", or are children of an element with that role.

In focus mode, key presses are not intercepted. Users may explicitly switch to this mode, but screen readers will generally also switch to focus mode automatically when a user is interacting with form fields. In focus mode, keyboard behavior matches that of keyboard users without a screen reader.

The distinction between browse and focus mode is not present in other operating systems (such as macOS and Gnome/Linux). Here, screen reader commands are generally triggered using additional modifier keys (such as Command, Ctrl, Option, Meta). Key presses won't be intercepted by screen readers, unless they have been switched into specific modes such as VoiceOver/macOS's "single-key quick navigation". For HTML content, role="application" has no effect on these platforms.

Benefits

Users will be able to turn off single-key shortcuts, or modify them to include at least one non-character key, so they can avoid accidentally triggering them.
Keyboard-only users who have dexterity challenges can avoid problematic single character shortcuts by modifying/remapping them.
Allowing all shortcut keys to be remapped can help users with some cognitive disabilities, allowing them to assign actions to the same shortcuts that they may already be familiar with from other sites or applications.

Examples

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.

Alternate Control

Keyboard-only users are in a long issues thread. While reading the thread they accidentally hit the S key, which moves focus to the search bar at the top of the document. This causes them to lose their place and train of thought. However, a mechanism is provided to allow users to change character-key shortcuts. They change the shortcut to include another key so they can avoid future interruptions.

Related Resources

Resources are for information purposes only, no endorsement implied.

Key event logger – logs all JavaScript key events that reach the document; useful to verify if a specific combination of platform, user agent, and assistive technology fires key events.
Accessibility Developer Guide: Browse and Focus Modes.

Techniques

Each item in this section represents a technique or combination of techniques that the Accessibility Guidelines Working Group deems sufficient for meeting this success criterion. A technique may go beyond the minimum requirement of the criterion. There may be other ways of meeting the criterion not covered by these techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.

Sufficient Techniques

G217: Providing a mechanism to allow users to remap or turn off character key shortcuts

Failures

The following are common mistakes that are considered failures of this success criterion by the Accessibility Guidelines Working Group.

F99: Failure of Success Criterion 2.1.4 due to implementing character key shortcuts that cannot be turned off or remapped

Key Terms

assistive technology

hardware and/or software that acts as a user agent, or along with a mainstream user agent, to provide functionality to meet the requirements of users with disabilities that go beyond those offered by mainstream user agents

Note 1

Functionality provided by assistive technology includes alternative presentations (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible).

Note 2

Assistive technologies often communicate data and messages with mainstream user agents by using and monitoring APIs.

Note 3

The distinction between mainstream user agents and assistive technologies is not absolute. Many mainstream user agents provide some features to assist individuals with disabilities. The basic difference is that mainstream user agents target broad and diverse audiences that usually include people with and without disabilities. Assistive technologies target narrowly defined populations of users with specific disabilities. The assistance provided by an assistive technology is more specific and appropriate to the needs of its target users. The mainstream user agent may provide important functionality to assistive technologies like retrieving web content from program objects or parsing markup into identifiable bundles.

Example

Assistive technologies that are important in the context of this document include the following:

screen magnifiers, and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc. in order to improve the visual readability of rendered text and images;
screen readers, which are used by people who are blind to read textual information through synthesized speech or braille;
text-to-speech software, which is used by some people with cognitive, language, and learning disabilities to convert text into synthetic speech;
speech recognition software, which may be used by people who have some physical disabilities;
alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard (including alternate keyboards that use head pointers, single switches, sip/puff and other special input devices.);
alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.

conformance

satisfying all the requirements of a given standard, guideline or specification

keyboard shortcut

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

mechanism

process or technique for achieving a result

Note 1

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 2

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

process

series of user actions where each action is required in order to complete an activity

relied upon

the content would not conform if that technology is turned off or is not supported

technology

mechanism for encoding instructions to be rendered, played or executed by user agents

Note 1

As used in these guidelines "web technology" and the word "technology" (when used alone) both refer to web content technologies.

Note 2

Web content technologies may include markup languages, data formats, or programming languages that authors may use alone or in combination to create end-user experiences that range from static web pages to synchronized media presentations to dynamic web applications.

user agent

any software that retrieves and presents web content for users

user interface component

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

Note 1

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 2

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

Note 3

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

Test Rules

The following are Test Rules for certain aspects of this Success Criterion. It is not necessary to use these particular Test Rules to check for conformance with WCAG, but they are defined and approved test methods. For information on using Test Rules, see Understanding Test Rules for WCAG Success Criteria.

No keyboard shortcut uses only printable characters