Keyboard shortcut discoverability: make it obvious (and safe)

Intro

Keyboard shortcuts are great — but they can become a trap if they fire while someone is typing, or if they clash with assistive technologies. The fix is not “no shortcuts”; it’s discoverable, scoped, optional shortcuts, with safe announcements.

See the micro-demo: Keyboard shortcut discoverability demo.

Checklist (8–12 bullets)

• Make shortcuts discoverable: show a hint (e.g., “Press ? for shortcuts”), and include a visible Keyboard shortcuts button/menu item.
• Provide a help dialog with a clear list (key → action). Make it keyboard-accessible: role="dialog", aria-modal, Escape to close, focus trap, restore focus.
• Don’t break typing: ignore shortcuts when focus is in <input>, <textarea>, or contenteditable — and when modifier keys are held.
• Provide a way to disable shortcuts (a settings toggle). Persist the preference.
• Keep parity with mouse/touch: every shortcut should have a visible button/control that does the same thing.
• Avoid global single-letter shortcuts that can conflict with screen readers or browser features; scope them to a region/app and keep them optional.
• Announce changes politely (e.g., “Archived”, “Selected…”) via role="status" — and never move focus just to announce.
• Use stable selection semantics (e.g., listbox or roving tabindex) so keyboard users know what’s selected.
• Be careful with “?”: on many keyboards it’s Shift + another key; show both the key and the action in docs.
• Test the failure mode: type j k e ? in a search box and confirm nothing triggers.

Related

• Focus ring demo (keyboard navigation visibility)
• Visible focus rings (note)
• Tooltips (don’t be hover-only) — discoverability without requiring a mouse