A keyboard shortcut only works as a shortcut if the menu path is still there too

What it is

An accelerator (a keyboard shortcut, a gesture, a macro) is a shortcut to an action already reachable through a base path — a menu, a button. It doesn't create new functionality; it just offers a faster way to walk a path that already exists. The relationship between the two is coexistence, not substitution: the base path handles "findable without memorizing," the accelerator handles "faster once memorized." Removing either one hurts whichever population still depends on the other.

Why it happens

The base path carries discoverability: a user who doesn't know a function's name or even that it exists can only find it by browsing the interface's visible entry points, and that browsing is itself the process of learning the function exists and where it lives. The accelerator carries speed: a user who already knows the function exists and how to use it doesn't need to repeat the browse-and-confirm step — they can execute the memorized action directly. Keep only the accelerator and drop the base path, and everyone is now required to memorize by rote before they can use the function at all, denying the chance to learn it naturally by browsing. Keep only the base path and drop the accelerator, and every user's speed is pinned to the browse-and-confirm tier — even someone who has fully memorized the action can't skip that step.

Where it stops holding

Not every function deserves an accelerator: only actions executed repeatedly and frequently enough to justify the time a user would spend memorizing them are worth the design and maintenance cost of an accelerator path. Giving low-frequency functions accelerators costs more to build and maintain than it returns, and it also inflates the total number of accelerators past what users can realistically hold in memory — diluting the visibility of the accelerators for the genuinely high-frequency functions.

Applying it

• For every action reachable only through an accelerator (shortcut, gesture, command) with no equivalent entry point in the visible interface, check whether a base path exists. If it doesn't, add one — even a slower one — so a user encountering this function for the first time can still discover it by browsing.
• Annotate the base path itself (menu items, buttons) with the corresponding accelerator hint (a shortcut combination shown next to the menu item, say), so users taking the base path passively pick up the accelerator while completing the action, shrinking the extra learning step needed to switch over later.
• Verification: list every accelerator in the product and check, one by one, whether an equivalent entry point exists in the visible interface (menus, toolbars, a command palette). Any accelerator with no matching entry point is a memory-only island that needs a base path added immediately.

Related

• Same group: A11.04.1 Novices rely on recognition, experts rely on recall · A11.04.4 The upgrade path from novice to expert needs to be visible in the interface
• Adjacent: A6.05 Recognition over recall
• Search: keyboard shortcut · accelerator design · discoverability