Single-key shortcuts and the ADA

Shortcuts that misfire

Many document viewers and case systems add keyboard shortcuts such as d to download or / to jump to search. For a person who dictates, a spoken sentence can be turned into a stream of key presses, and a stray letter can delete, archive or navigate away. People who type with one finger or a mouth stick also hit keys by accident.

Success Criterion 2.1.4 applies when a shortcut is made of character keys only: letters, numbers, punctuation or symbols, including sequences like pressing g then a. Shift+/ to produce a question mark still counts. In that case at least one of three things must be true.

• Turn off: there is a way to disable the shortcut.
• Remap: there is a way to reassign it to include a non-printable key such as Ctrl or Alt.
• Active only on focus: the shortcut for a component works only while that component has focus.

Shortcuts that already need a modifier such as Ctrl or Alt are not affected.

Where public tools add single-key hotkeys

• Court e-filing viewers with d for download and p for print.
• Library catalogs that use / or n to move around results.
• Embedded email, ticketing or document tools that came with single-letter defaults.
• Web apps that copy desktop apps, such as "press c to compose".

The shortcuts are usually added as a convenience for staff and then shipped to the public unchanged. A visible switch in settings is often all the fix needs.

Option 1: a switch that turns shortcuts off

A preference stored for the user, honored before any shortcut runs. Put it in a place that can be reached with the keyboard, for example a "Keyboard shortcuts" setting on the page.

document.addEventListener("keydown", e => {
  if (e.key === "d") downloadDocument();
  if (e.key === "p") printDocument();
});

const prefs = JSON.parse(
  localStorage.getItem("docketPrefs") || '{"shortcuts":true}'
);
shortcutToggle.checked = prefs.shortcuts;
shortcutToggle.addEventListener("change", () => {
  prefs.shortcuts = shortcutToggle.checked;
  localStorage.setItem("docketPrefs", JSON.stringify(prefs));
});

document.addEventListener("keydown", e => {
  if (!prefs.shortcuts) return;
  if (e.ctrlKey || e.metaKey || e.altKey) return;
  if (e.target.closest("input, textarea, select, [contenteditable]")) return;
  if (e.key === "d") downloadDocument();
  if (e.key === "p") printDocument();
});

Option 2: let people choose the keys

A hard-coded map becomes a user-editable map. Bindings must be allowed to include a modifier key.

const KEYS = { d: downloadDocument, p: printDocument };
document.addEventListener("keydown", e => KEYS[e.key]?.());

// Loaded from the user's settings page, e.g. {"Alt+KeyD": "download"}
const bindings = loadBindings();
const actions = { download: downloadDocument, print: printDocument };

document.addEventListener("keydown", e => {
  const combo = (e.ctrlKey ? "Ctrl+" : "") +
                (e.altKey ? "Alt+" : "") + e.code;
  const name = bindings[combo];
  if (name) { e.preventDefault(); actions[name](); }
});

Option 3: work only while the component has focus

A results list that supports "n" for next page and "p" for previous page can keep that behavior if the keys act on the list itself, not on the whole document.

document.addEventListener("keydown", e => {
  if (e.key === "n") nextPage();
  if (e.key === "p") prevPage();
});

const results = document.getElementById("results");   // tabindex="0"
results.addEventListener("keydown", e => {
  if (e.key === "n") nextPage();   // only while the list is focused
  if (e.key === "p") prevPage();
});

Hardware keyboards in mobile apps

Apps are covered too. Tablets and phones with hardware keyboards expose the same risk. On iOS and Android, ask for a modifier key by default. In Compose, onKeyEvent only receives events while that node or one of its children has focus, so attach it where focus actually is.

SwiftUI:

Button("Download") { download() }
    .keyboardShortcut("d", modifiers: [])

Button("Download") { download() }
    .keyboardShortcut("d", modifiers: .command)

Jetpack Compose:

Modifier.onKeyEvent { event ->
    if (event.type == KeyEventType.KeyDown && event.key == Key.D) {
        download(); true
    } else false
}

Modifier.onKeyEvent { event ->
    if (event.type == KeyEventType.KeyDown &&
        event.isCtrlPressed && event.key == Key.D) {
        download(); true
    } else false
}

Verifying the fix

1. List every shortcut the product documents, and search the code for keydown and keypress handlers to find undocumented ones. Access keys that are activated with a modifier are not affected.
2. Click into the page body, press each plain letter, number and symbol, and note what happens. Then try Shift+letter.
3. For each shortcut that fires, find the switch, the remap field or the focus condition that makes it compliant.
4. If you have speech input software, dictate a sentence on the page and see whether any command runs.

Automated tools cannot see what a script does with a key press, so this one is manual.

Common mistakes and a ship-it list

• Treating Shift+/ or AltGr combinations as modifier shortcuts. They still produce a character.
• Offering the off switch only in a long help article, not in a setting.
• Turning shortcuts off for one session only, so they are back on the next page load.
• Letting shortcuts fire while a text field has focus, so typing triggers actions.

Ship it when every single-key shortcut can be turned off, remapped with a modifier, or fires only while its own component is focused, and the choice is saved.

See WCAG 2.1 AA and the ADA for how this level A criterion sits in the standard.

Sources

• Understanding SC 2.1.4: Character Key Shortcuts (W3C), opens in a new tab
• 28 CFR Part 35, Subpart H: Accessibility of Web Information and Services (eCFR), opens in a new tab

Standard version: WCAG 2.1 (W3C Recommendation, 5 June 2018), as named in the Title II web rule. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official ADA statute and regulations, and ask a lawyer how they apply to you.