Menu button

Problem Context

• An object, row, card, toolbar, or header has more actions than should be visible at once.
• The commands are contextual and short enough to scan without search.
• Users need to know whether each item runs an action, opens a destination, is unavailable, or requires a confirmation step.
• The popup should be transient and dismissible without committing a value.
• The interaction must work for pointer, keyboard, touch, and assistive technology users.

Selection Rules

• Choose a menu button when one trigger reveals a short local set of actions or command-like links.
• Use a command palette when the command set is broad, searchable, cross-product, shortcut-driven, or includes navigation across distant areas.
• Use a select, listbox, radio group, or checkbox group when users are choosing values for a form field rather than invoking commands.
• Use a confirmation dialog after a high-risk menu item is chosen when the user must review object, consequence, and recovery before the action runs.
• Use visible buttons instead of a menu when there are only one or two frequent safe actions and hiding them would slow the task.
• Use a header or global navigation pattern when the main design problem is screen orientation or top-level destination switching, not a local trigger-popup widget.
• Do not use an unnamed icon as the only clue for unfamiliar actions; the trigger and every item need an accessible name that explains the target or outcome.
• Keep menu content to menu items, optional sections, separators, shortcuts, descriptions, and selection indicators; move forms, complex editors, tables, and long content into dialogs, popovers, panels, or pages.

Required States

• Closed trigger state with visible or accessible name.
• Open state with aria-expanded true and a controlled menu.
• First active item after opening from Enter, Space, or Down Arrow.
• Last active item after opening from Up Arrow.
• Hover and keyboard focus state for each menu item.
• Activated safe command state with menu closed and focus returned.
• Escape dismissed state with no command committed.
• Outside-click or blur dismissal state.
• Disabled or unavailable menu item state.
• Destructive or high-risk command state that opens confirmation or recovery.
• Grouped section or separator state when commands have different scopes.
• Long label, narrow viewport, and forced-colors states.

Interaction Contract

• The trigger is a button or equivalent control with a clear name, aria-haspopup set to menu or true, and aria-expanded synchronized with visibility.
• The popup has role menu, is labelled by the trigger or a clear menu label, and contains only menuitem, menuitemcheckbox, menuitemradio, group, and separator semantics as appropriate.
• Opening the menu moves focus to a menu item or sets aria-activedescendant to the active item.
• Arrow keys move the active item inside the menu and do not scroll the page while the menu owns focus.
• Enter or Space activates the focused menu item or toggles menu item selection according to the item role.
• Escape closes the menu and returns focus to the trigger.
• Tab leaves the transient menu by closing it and continuing in the page focus order.
• Disabled items are perceivable as unavailable and cannot be activated.
• Destructive items either open a confirmation or provide an immediate recovery path instead of running silently from a small menu.
• The menu closes after normal command activation unless the item intentionally opens a submenu or toggles a menuitemcheckbox or menuitemradio state.

Implementation Checklist

• Inventory the commands and keep only a short contextual set in the menu.
• Give the trigger a visible label when possible, or a precise accessible name such as Report actions when space requires an icon.
• Set aria-haspopup, aria-expanded, and aria-controls consistently with the popup state.
• Use role menu plus menuitem roles only when implementing composite menu keyboard behavior; use simpler links or buttons when a normal disclosure list is enough.
• Move focus into the menu on open, track one active item, and return focus to the trigger on Escape, outside dismissal, or activation.
• Implement Arrow Up, Arrow Down, Home, End, typeahead when useful, Enter, Space, Escape, pointer activation, and touch activation.
• Expose disabled, checked, destructive, shortcut, description, and section states in text and semantics, not only color.
• Route destructive menu items into confirmation, undo, or recovery flows with the affected object still visible.
• Test screen reader announcements, keyboard focus, zoom, narrow width, forced colors, touch hit area, portal placement, clipping, and scroll containers.

Common Generated-UI Mistakes

• Using a menu button for long value selection that should be a select, listbox, combobox, or multi-select.
• Using role menu for ordinary page navigation or a simple list of links without implementing menu keyboard behavior.
• Opening only on hover or closing before keyboard users can reach the first item.
• Leaving aria-expanded stale after the menu opens or closes.
• Putting inputs, sliders, date pickers, editable tables, or large explanatory content inside the menu.
• Hiding primary or emergency recovery actions in a compact overflow menu.
• Using identical item labels such as Open, Open, Open without object context.
• Running destructive commands from the menu without confirmation, undo, or object-specific feedback.

Critique Questions

• Is this a short local command set, or does the user need searchable product-wide commands?
• Can users predict what the trigger controls before opening it?
• Are item labels verbs or destinations with enough object context?
• Does keyboard focus move into the menu, move between items, and return to the trigger on close?
• Are disabled, destructive, and selected items exposed without relying on color alone?
• Is any form, editor, long content, or high-risk review hiding inside a widget that should be a dialog, panel, or page?