2.1.4 Character Key Shortcuts

Level A
Operable
Since WCAG 2.1

Summary

This criterion protects two groups in particular. Speech input users dictate text and commands out loud, and their software turns that speech into keystrokes: if the word "hey" is picked up while a mail app is open and E archives the current message, a stray syllable has just destroyed data. Keyboard users with tremors, motor impairments, or simply a tendency to mistype are the second group: a single accidental keypress should not fire an irreversible action. Shortcuts that require a modifier such as Ctrl, Alt, or Cmd are safe by design, because dictation and stray keypresses do not produce chorded input, so this criterion, introduced at Level A in WCAG 2.1, targets only shortcuts made entirely of printable characters (letters, numbers, punctuation, symbols).

The auditor's mental model is a three-way escape hatch. First establish whether the page or app implements any single printable-character shortcut at all; if none exists, the criterion passes as not applicable in effect. If one exists, it passes if any one of three things is true: the user can turn it off, the user can remap it to include a non-printable key, or the shortcut only works while the specific component it controls has focus. A single-key shortcut that is always live, with no setting to disable or change it, is the fail.

Official wording

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.

Success Criterion 2.1.4 Character Key Shortcuts, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, 5 October 2023 (updated 12 December 2024). Copyright © 2023-2024 World Wide Web Consortium. https://www.w3.org/copyright/document-license-2023/. Reproduced unmodified under the W3C Document License.

EN 301 549 mapping

Web pages: Clause 9.2.1.4
Software and native apps: Clause 11.2.1.4
Closed functionality (kiosks, terminals): Systems closed to keyboards must be operable without a keyboard interface (clause 5.1.6.1).

Clause 9.2.1.4 applies this criterion to web pages unchanged and clause 11.2.1.4 applies it to software with keyboard access. Systems closed to keyboards must instead meet clause 5.1.6.1 on operation without a keyboard interface.

Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.

In practice

Web

Start with an inventory. Load each page, place focus on the page body (click empty space or press Escape so no text field has focus), and press through the printable keys: letters a to z, digits, and common punctuation such as slash, question mark, and full stop. Watch for anything happening: items being archived or starred, focus jumping between messages or posts, panels opening, media playing or pausing. The classic offenders are mail clients, feed readers, and project boards that copied the j/k navigation pattern, E to archive, X to select, or slash to focus search. A question mark that opens a shortcut cheat sheet is itself evidence that single-key shortcuts exist, and the cheat sheet is a convenient inventory source.

For each single-character shortcut found, check the escape hatches in order. Look in settings or preferences for a "keyboard shortcuts" toggle (turn off) or a shortcut editor that accepts combinations like Ctrl plus the key (remap). If neither exists, test the focus condition: does the shortcut fire only when its component has focus? Arrow keys and letter jumps inside a focused listbox or grid are fine; a letter that fires while focus sits on the page body, or on an unrelated control, is globally active and fails unless it can be disabled or remapped.

Developer tools help confirm what manual pressing suggests. In the browser console, inspect keydown and keypress listeners registered on document or window; a global listener switching on plain letter codes with no modifier check is the implementation signature of a failing shortcut. Also verify that the "turn off" mechanism genuinely works: toggle it, retest the keys, and confirm the setting persists across the session.

iOS

The European standard applies this requirement to software with keyboard access, so a native app is in scope wherever a hardware keyboard can be connected, which on iPhone and iPad is effectively always. Test with a Bluetooth or Smart Keyboard attached. iOS apps declare shortcuts with UIKeyCommand; holding down the Cmd key shows the app's shortcut overlay, which gives you a fast inventory. Most entries will include Cmd or another modifier and are out of scope. What you are hunting for is a key command whose input is a bare letter, number, or punctuation character with no modifier flags, active app-wide.

If you find one, apply the same three-way test: is there an in-app setting to disable it, a way to remap it to include a modifier, or is it registered only on a specific focused view (for example, single-key handling inside a focused game board or list) rather than globally? Also press the printable keys directly with focus outside any text field, since not every handler appears in the Cmd overlay: low-level pressesBegan handling can implement shortcuts the discovery overlay never lists. Systems genuinely closed to keyboard connection fall under the European standard's requirement for operation without a keyboard interface instead, but that is rare for consumer mobile apps.

Android

The same scoping applies: with a hardware keyboard connectable over Bluetooth or USB, an Android app's key handling is in scope. Connect a keyboard and, where the app or launcher supports it, open the system shortcut helper (typically Meta plus slash) to list declared shortcuts; then press through bare letters, numbers, and punctuation with focus on the app's main content, watching for triggered actions. Apps implement key handling through dispatchKeyEvent, onKeyDown, or key event callbacks in Compose; a handler that reacts to an unmodified printable key regardless of which view has focus is the pattern that fails.

As on iOS, most Android apps that offer shortcuts at all use Ctrl or Alt combinations, which this criterion ignores entirely. Where a bare-character shortcut exists, check the app's settings for a disable toggle or a remapping screen, and check whether the key only acts when its component holds focus (letter-to-jump inside a focused RecyclerView list is focus-scoped and fine). Grade a globally live, unconfigurable single-key action as a fail even though most users will never attach a keyboard: speech input and switch access on Android can synthesise the same key events a hardware keyboard produces.

Pass and fail examples

Passes:

A mail app archives on E and navigates on J and K, and its settings include a "keyboard shortcuts" toggle that disables all of them: turn off mechanism present.
A project board lets users open a shortcut editor and change X (select card) to Ctrl+X: remap to include a non-printable key.
A custom listbox moves selection when the user types a letter, but only while the listbox itself has focus: active only on focus.
An app whose every shortcut requires Ctrl, Cmd, or Alt: no single printable-character shortcut exists, so there is nothing to grade.
A slash key that focuses the search field, disableable from the same settings page as the site's other shortcuts.

Fails:

A feed reader where J and K move between posts and M mutes a thread from anywhere on the page, with no setting to disable or remap them.
A media player where the S key skips the current track whenever the page body has focus, and the only "setting" is a help overlay listing the shortcuts.
A web chat where pressing D while a conversation row is merely hovered (not focused) deletes it, with no configuration available.
A native app registering a bare letter key command that fires app-wide from any screen, offering no toggle and no remap.

Not a fail under this criterion:

Shortcuts built on Ctrl, Cmd, Alt, or another non-printable key: out of scope entirely, whatever they do.
Enter, Escape, arrow, function, and other non-printable keys used alone: not printable characters, so not covered here.
Typing letters into a focused text field: that is data entry, not a shortcut.
Browser-native behaviour such as spacebar scrolling or the user agent's own accesskey activation chords: user agent functionality, not shortcuts implemented in the content.
Interactive functionality that cannot be reached or operated by keyboard at all: that is a SC 2.1.1 Keyboard finding, not a character key one.

Commonly confused with

SC 2.1.1 Keyboard. 2.1.1 is about keyboard support being missing; 2.1.4 is about keyboard shortcuts existing in a dangerous form. An app with no keyboard shortcuts at all can fail 2.1.1 and has nothing to grade under 2.1.4; an app with excellent keyboard support can still fail 2.1.4 because its single-key shortcuts cannot be switched off.
SC 2.1.2 No Keyboard Trap. A trap holds focus so the user cannot leave a component. A rogue single-key shortcut does the opposite kind of damage: focus moves freely, but ordinary typing triggers unintended actions. Different failure, different evidence.
User agent and platform shortcuts. Browser and OS behaviour (spacebar scroll, the modifier chord a browser assigns to accesskey) is not "implemented in content". Grade only shortcuts the author's own code creates.
Focus-scoped widget keys. Letter-to-jump in a focused list, or single-key controls inside a focused game canvas, satisfy the "active only on focus" condition by design. Do not file these as fails; the criterion explicitly permits them.

How AUDITSU tests this

AUDITSU's audit walkthrough covers character key shortcuts as part of its keyboard checks on each screen. The walkthrough prompts you to place focus on the screen's main content, sweep the printable keys, and record any action that fires without a modifier; where one is found, it asks in turn whether a disable setting, a remap mechanism, or focus scoping applies. Each screen records a pass, fail, or not applicable result with your evidence attached (the shortcut, the key, and the settings screens you checked), so the finding lands in the report against the exact screen where the shortcut is live.

For the full guided workflow, see the audit platform.