Windows, menus, and shortcuts form one command system
Aliases: menu bar · accelerator · access key · command inventory
What it is
Windows collects an application’s functions inside the window. The title bar, the system menu, the app menu or ribbon, and keyboard shortcuts are three doors into one command inventory. The menu lists everything the window can do right now. A shortcut is an alias into that list, not a parallel UI. Alt moves focus into the menu; underlined access keys hit an item once the menu is open; Ctrl-chords fire the same command with the menu closed.
This is how functions are discovered, reached from the keyboard, and scoped to a window—not how freely a window may be resized. Actions that live only on a toolbar, cannot be found in the menu, and are not labeled beside the menu item split the inventory into three unacquainted copies. Mouse users, keyboard users, and screen-reader users then each meet a different subset.
Why it happens
The window is the command’s scope. Minimize, maximize, close, and move-to-another-desktop are system operations on that scope; they belong on the title bar and system menu, and the app should not ship a second set of window controls that fight them. The app’s own commands hang on the menu or ribbon, with the shortcut written on the right of the item—so the menu does both discovery and shortcut teaching. A shortcut is predictable because it points at a row already in the inventory; a key with no row is undeclared behavior, and more likely to collide with system chords.
Access keys (letters once the menu is visible) and accelerators (chords available at any time) are not the same layer. The first jumps inside a visible list; the second bypasses the menu. Both map back to one command, and state—dimmed, checked, on/off—must hold on the menu item, the toolbar button, and the shortcut together. Otherwise a shortcut fires a command the menu shows as unavailable, or the reverse.
Where it stops holding
Immersive fullscreen (presentations, games, media) hides the menu bar, so the inventory must move to a system-provided overflow or to an explicit path that restores the menu after leaving fullscreen. On touch-first devices without a stable keyboard, access keys are costly to discover; the menu still has to be tappable, and shortcuts remain accelerators rather than the only door. A compact command bar and a classic desktop menu can coexist in different windows of one product, but they must not disagree inside a single window. In browsers and multi-document tools, whether Close targets the current document or the whole app has to be explicit, or the wrong object disappears. System shortcuts—window switching, lock, input method—must not be swallowed; on collision, the app yields.
Applying it
- Keep one command inventory per window: every action is findable in the menu or ribbon, with its shortcut labeled on the item.
- Toolbars hold a subset of that inventory; they do not invent actions missing from the menu. Dimmed, checked, and on/off states stay in sync across menu, toolbar, and shortcut.
- Do not draw a second minimize/close control, and do not intercept system chords. Access keys and accelerators both point at the same inventory row.
- Verify by hiding the toolbar and completing the main task from the menu alone, then hiding menu cues and completing it from shortcuts, checking that labels match keystrokes. Any “on the button but not in the menu” or “the key fired while the menu showed unavailable” means the inventory has split. Then press a system shortcut and confirm the app did not eat it.