Component contract
What it must accomplish
Keep secondary actions available without competing with the primary task.
ClosedOpenItem focusedSelectedDisabled
Usage
Choose the control by behavior
Use it when
- Several related commands need compact access
- Actions apply to one object or context
- The list can be understood without persistent visibility
Use another pattern when
- Destinations form primary navigation
- The options are required form input
- A critical action would become undiscoverable
Anatomy
Stable parts create a reliable contract
- 1Trigger
- 2Menu surface
- 3Menu items
- 4Optional groups and separators
- 5Optional check or radio state
Explanation
Interaction and keyboard behavior
- Enter, Space, or Arrow Down opens from the trigger
- Arrow keys move between items
- Escape closes and returns focus
- Typeahead may move to matching items
Why this matters
Visual similarity does not guarantee behavioral equivalence. The component contract must preserve state, focus, semantics, and recovery across input methods.
Cross-system baseline
Accessible behavior
- Use a button trigger with expanded state
- Use menu semantics only for application-style commands
- Keep disabled items perceivable but not focusable according to the chosen pattern
- Return focus predictably
Responsive considerations
Adapt the decision—not only the dimensions
Reposition the surface within the viewport; on touch devices, consider a sheet when commands need more context or larger targets.
Content considerations
Language is part of the component
- Use concise verb phrases for actions
- Group by consequence
- Name dangerous actions explicitly
Common mistakes
Patterns that weaken the experience
01
Using a menu for ordinary site links
02
Opening on hover alone
03
Clipping focus or content at viewport edges
Comparison
What to study across systems
Desktop platforms bring established menu conventions; web systems differ on whether a disclosure, popover, or true ARIA menu is appropriate.
Open comparison