WCAG 2.1.4 Character Key Shortcuts

What it asks

Many web apps copy the keyboard shortcuts of desktop software: press "j" and "k" to move through a list, "/" to jump to search, "e" to archive, "?" to show help. For someone typing with their fingers, these are handy. For someone using speech recognition, they are a hazard, because dictated words become keystrokes. Saying "Okay, email Kate" can archive three messages before the first word is recognised.

The rule covers shortcuts made of a single printable character with no modifier key. That means a letter, a number, punctuation or a symbol, on its own. Shortcuts that use Control, Alt, Command or Shift together with a character are not covered, because dictation does not produce them by accident.

For each such shortcut, at least one of three things must be true. The person can turn it off. The person can remap it to include a non-printable key such as Control or Alt. Or the shortcut is only active while the component it belongs to has focus, so a letter typed anywhere else on the page does nothing.

It does not ban single-key shortcuts, and it does not apply to the browser’s own shortcuts or to keys a text field uses to accept typing. It applies to shortcuts the page itself sets up, usually with a keyboard listener at the document level.

Its official name is success criterion 2.1.4 Character Key Shortcuts, at Level A. It was added in WCAG 2.2, under guideline 2.1 Keyboard Accessible and the principle Operable. The W3C’s normative text says, in part:

“The keyboard shortcut for a user interface component is only active when that component has focus.”

From WCAG 2.2, W3C. Full explanation: Understanding 2.1.4 Character Key Shortcuts.

Who it helps

People who use speech recognition to control their computer. Their dictated words can be received by the page as a stream of single keystrokes, and every one of those keystrokes is a shortcut waiting to fire.

People with tremors or limited dexterity, who press keys by accident more often, and people with cognitive disabilities, who may not realise that a letter they pressed did something.

What passes and what fails

These pass

• An email client with "j" and "k" list shortcuts and a settings page where keyboard shortcuts can be turned off.
• A kanban board whose single-letter shortcuts work only while a card has focus.
• A site where "/" focuses the search box, with an option to remap the shortcut to "Control" and "/".
• A page that uses only modifier-key shortcuts, such as "Control" and "K" for the command menu.
• A page with no keyboard shortcuts at all. The criterion does not apply.

These fail

• "j" and "k" list navigation that is active everywhere on the page, with no setting to turn it off.
• "/" that focuses the search box even while the person is typing in another field.
• A video player where "f" toggles full screen whenever the page has focus, not just the player.
• A single-letter shortcut that can be disabled, but only through a browser extension, not the page itself.

How to test it by hand

1. Look for a keyboard shortcuts help page, a "?" overlay or a settings section listing shortcuts. Also check the product documentation.
2. With focus on the page body, not in a text field, press each letter, number and symbol key and watch what happens.
3. For each shortcut that fires, check whether it is active only while a particular component has focus: click elsewhere on the page and press it again.
4. If it fires anywhere, look for a setting to turn it off or to change it to include a modifier key.
5. A shortcut with none of the three, no off switch, no remapping and no focus restriction, fails.

What automated testing can decide

What a machine can decide

Automated testing can find the single-key shortcuts a page sets up and show which keys do something when nothing on the page has focus. A key that acts with no component focused is a document-wide shortcut, and that is the thing the criterion applies to.

What it cannot

Finding a shortcut is not deciding the criterion. Whether it can be turned off or remapped is a question about a settings page a tool may never reach, and whether a shortcut is restricted to a focused component needs trying it in both states. Those are questions for a person.

How Dreven handles it

Dreven finds the single-key shortcuts on your pages and shows you each one, with the key, the page and what happened when it was pressed.

A reviewer decides each result, with the question of whether the shortcut can be turned off, remapped or limited to a focused component, and the report says how each one was decided.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 2.1.1 Keyboard (Level A). Everything must work from a keyboard. 2.1.4 is about keys doing too much, not too little.
• 3.2.2 On Input (Level A). Pressing a key should not change the page in a way the person did not expect.
• 2.1.2 No Keyboard Trap (Level A). A shortcut that moves focus must not leave the person somewhere they cannot leave.

Questions people ask

All WCAG 2.2 criteria, in plain words