WCAG 2.1.4 · Level A · EN 301 549 9.2.1.4

Character Key Shortcuts

Requires that single-character shortcuts can be turned off, remapped to include a modifier, or are active only on focus.

In brief

Single-key shortcuts such as "S" for search or "J" for next can be a gift for keyboard users, but they cause real trouble for people who use speech recognition, since spoken words can trigger them by mistake, and for people who press keys by accident.

This criterion requires that if a keyboard shortcut is made of only letters, punctuation, numbers or symbols, at least one of three things is true: it can be turned off, it can be remapped to include a modifier key, or it is active only when the component it belongs to has focus.

What does it cover?

  • What it covers: Shortcuts that use a single printable character, with or without Shift. A shortcut with Ctrl, Alt or Meta is not covered.
  • Turn off: A setting lets users disable the shortcut.
  • Remap: A setting lets users change it to include Ctrl, Alt or another non-printing key.
  • Active on focus: The shortcut only works while the specific component has focus, for example arrow keys inside a listbox.
  • Not covered: Shortcuts that already need a modifier key, access keys that browsers handle with their own modifier, and standard controls.
  • Out of scope: Keyboard operation of every function is 2.1.1. Timing of keystrokes is also in 2.1.1.

Who does it affect?

Speech recognition users, whose words can trigger single-key shortcuts accidentally. People with motor disabilities and tremors who press keys unintentionally. Screen reader users, whose single-letter navigation keys can clash with an application shortcut.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Predictable keyboard shortcuts are part of "operable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 2.1.4 by reference and turns it into separate clauses for each kind of ICT.

Where WCAG 2.1.4 appears in EN 301 549
ClauseType of ICTWhat it requires
9.2.1.4Web pagesWeb content must satisfy WCAG success criterion 2.1.4.
10.2.1.4Non-web documents (PDF, Office files)Documents must meet the same shortcut rule where the standard applies the criterion to them.
11.2.1.4Non-web software (native mobile apps)Software with single-character shortcuts must let users turn them off, remap them or limit them to focus.

Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 2.1.4 is the same in WCAG 2.1 and 2.2.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. A global single-key shortcut

A listener on the whole document that reacts to a bare letter is the typical failure.

Incorrect
document.addEventListener("keydown", e => {
  if (e.key === "s") openSearch();
});
Correct
document.addEventListener("keydown", e => {
  if (e.key === "s" && e.ctrlKey) { e.preventDefault(); openSearch(); }
});

2. Let users turn shortcuts off

A setting that disables single-key shortcuts satisfies the criterion.

Incorrect
// Shortcuts are always on
Correct
<label>
  <input type="checkbox" id="shortcuts" checked>
  Enable single-key shortcuts
</label>
<script>
document.addEventListener("keydown", e => {
  if (!shortcuts.checked) return;
  if (e.key === "s") openSearch();
});
</script>

3. Active only on focus

Limit the shortcut to the component it controls.

Incorrect
document.addEventListener("keydown", e => { if (e.key === "j") next(); });
Correct
list.addEventListener("keydown", e => {
  if (e.key === "j") next(); // works only while the list has focus
});

4. Ignore typing in fields

A shortcut must never fire while the user types in an input.

Incorrect
document.addEventListener("keydown", e => { if (e.key === "c") compose(); });
Correct
document.addEventListener("keydown", e => {
  const t = e.target;
  if (t.matches("input, textarea, select, [contenteditable]")) return;
  if (e.key === "c" && e.altKey) compose();
});

5. Offer remapping

Let users choose their own key combination.

Incorrect
const key = "s"; // hard-coded
Correct
const key = settings.get("searchKey") ?? "Ctrl+S";
// A settings page lets users change it

6. Access keys

The accesskey attribute uses a browser-specific modifier, but a plain letter can still clash with assistive technology. Use it sparingly and document it.

Incorrect
<a href="/search" accesskey="s">Search</a>
Correct
<a href="/search">Search</a> <!-- or a documented, remappable shortcut -->

Code examples for mobile

On native apps used with a hardware keyboard, use shortcuts with a modifier such as Command or Control, and keep single-key actions to the focused control.

iOS (SwiftUI)

import SwiftUI

struct SearchButton: View {
    var body: some View {
        // Avoid: a bare "s" with no modifier
        // .keyboardShortcut("s", modifiers: [])

        // A modifier makes it a deliberate command
        Button("Search") { openSearch() }
            .keyboardShortcut("f", modifiers: .command)
    }
}

Android (Jetpack Compose)

import androidx.compose.ui.Modifier
import androidx.compose.ui.input.key.*

// Avoid: reacting to a bare letter anywhere in the screen
fun Modifier.searchShortcut(onSearch: () -> Unit): Modifier =
    this.onKeyEvent { event ->
        // A modifier makes it a deliberate command
        if (event.type == KeyEventType.KeyDown && event.isCtrlPressed && event.key == Key.F) {
            onSearch(); true
        } else false
    }

How to test

  • List the shortcuts: Look in the help, the settings and the code for shortcuts that use a single printable key.
  • Try them: Press the key on the page and in a text field. Does it trigger an action? Does it fire while typing?
  • Look for a way out: Can the shortcut be turned off or remapped to include a modifier? Is it active only when its component has focus?
  • Use speech or a screen reader: Say a word or press single-letter navigation keys. Do shortcuts fire unexpectedly?
  • Check the code: Search for keydown and keypress listeners on document or window without a modifier check.
  • Check mobile: With a hardware keyboard attached, do single-key actions fire unexpectedly?
  • Use a checker as a starting point: Automated tools cannot find custom shortcuts. A person must inspect the product.

Common mistakes

  • Global single-letter shortcuts with no setting: The classic failure.
  • Shortcuts that fire while typing: Typing in a field triggers an action.
  • No way to disable or remap: At least one of the three options is required.
  • Treating Shift as a modifier: Shift plus a character is still a character key.
  • Hidden shortcuts: Users cannot turn off what they do not know exists. Document them.
  • Overusing accesskey: It can clash with assistive technology.
  • Forgetting widgets from third parties: Embedded players and editors add their own shortcuts.
  • Testing with a keyboard only: Speech recognition users are the ones most affected.

Sources

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.

Corpowid is recognized by Gartner

Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.

Have questions about Corpowid?

Let’s connect.

We will get back to you as soon as possible.