WCAG 2.1.4 — Character Key Shortcuts

What this requires

If a keyboard shortcut uses only letter, punctuation, number, or symbol characters — without modifier keys like Ctrl or Alt — at least one of the following must be true:

A mechanism is available to turn the shortcut off.
A mechanism is available to remap the shortcut to a non-printing key (Tab, Escape, function keys).
The shortcut is only active when the relevant UI component has focus.

The criterion exists because users with speech-input setups, sticky keys, or motor impairments can trigger single-key shortcuts accidentally, sometimes catastrophically.

How AI coding tools fail this

When asked to "add Gmail-style keyboard shortcuts", AI tools wire up a global keydown listener that watches for j, k, r, c, and similar and fires actions regardless of focus. A speech-input user dictating into a comment field triggers "reply" every time they say the word.

The second pattern: shortcut systems with no settings page to turn them off. The user discovers them by accident, can't disable them, and can't get a clean dictation surface.

The third: documenting shortcuts only in a help overlay, never in the markup. Screen-reader users can't discover what's active, and there's no accesskey style hint.

Failing examples

A global single-key shortcut with no off-switch and no focus scope:

useEffect(() => {
  const handler = (e: KeyboardEvent) => {
    if (e.key === "r") openReply();
    if (e.key === "j") nextMessage();
  };
  window.addEventListener("keydown", handler);
  return () => window.removeEventListener("keydown", handler);
}, []);

Passing examples

Scope the listener so the shortcut only fires when the inbox region has focus, and skip the handler while the user is typing:

function useInboxShortcuts(active: boolean) {
  useEffect(() => {
    if (!active) return;
    const handler = (e: KeyboardEvent) => {
      const target = e.target as HTMLElement;
      if (target.matches("input, textarea, [contenteditable]")) return;
      if (e.key === "r") openReply();
      if (e.key === "j") nextMessage();
    };
    window.addEventListener("keydown", handler);
    return () => window.removeEventListener("keydown", handler);
  }, [active]);
}

Plus a settings panel to disable or remap the shortcuts:

<fieldset>
  <legend>Keyboard shortcuts</legend>
  <label>
    <input
      type="checkbox"
      checked={shortcutsEnabled}
      onChange={(e) => setShortcutsEnabled(e.target.checked)}
    />
    Enable single-key shortcuts (j, k, r, c)
  </label>
</fieldset>

Edge cases

Modifier-key shortcuts (Ctrl+S, Cmd+K) are not in scope. The criterion targets bare letters and symbols.
Activating shortcuts within a focused widget is fine — Arrow keys in a menu, J/K in a list with role="listbox". The criterion targets shortcuts that work outside the widget's context.
Tab and Escape are non-printing and not in scope.
accesskey attributes are exempt — the browser activates them with a modifier key.
Voice-input safety is the original motivation. Test with Windows Voice Access or macOS Voice Control before claiming the shortcut set is safe.

How Jeikin handles this

The scanner flags keydown and keyup listeners attached to window or document that match single-character keys without a modifier or focus check, and maps each to WCAG 2.1.4. The dashboard tracks each finding and records whether the shortcut is gated by focus, remappable, or disable-able. The evidence is the review pass.

References

W3C — Understanding 2.1.4 Character Key Shortcuts (opens in new tab)