Requires that single-character shortcuts can be turned off, remapped to include a modifier, or are active only on focus.
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.
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.
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.
| Clause | Type of ICT | What it requires |
|---|---|---|
| 9.2.1.4 | Web pages | Web content must satisfy WCAG success criterion 2.1.4. |
| 10.2.1.4 | Non-web documents (PDF, Office files) | Documents must meet the same shortcut rule where the standard applies the criterion to them. |
| 11.2.1.4 | Non-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
A listener on the whole document that reacts to a bare letter is the typical failure.
document.addEventListener("keydown", e => {
if (e.key === "s") openSearch();
});document.addEventListener("keydown", e => {
if (e.key === "s" && e.ctrlKey) { e.preventDefault(); openSearch(); }
});A setting that disables single-key shortcuts satisfies the criterion.
// Shortcuts are always on<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>Limit the shortcut to the component it controls.
document.addEventListener("keydown", e => { if (e.key === "j") next(); });list.addEventListener("keydown", e => {
if (e.key === "j") next(); // works only while the list has focus
});A shortcut must never fire while the user types in an input.
document.addEventListener("keydown", e => { if (e.key === "c") compose(); });document.addEventListener("keydown", e => {
const t = e.target;
if (t.matches("input, textarea, select, [contenteditable]")) return;
if (e.key === "c" && e.altKey) compose();
});Let users choose their own key combination.
const key = "s"; // hard-codedconst key = settings.get("searchKey") ?? "Ctrl+S";
// A settings page lets users change itThe accesskey attribute uses a browser-specific modifier, but a plain letter can still clash with assistive technology. Use it sparingly and document it.
<a href="/search" accesskey="s">Search</a><a href="/search">Search</a> <!-- or a documented, remappable shortcut -->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.
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)
}
}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
}keydown and keypress listeners on document or window without a modifier check.accesskey: It can clash with assistive technology.