UX Patterns Guide
UI + UX Disclosure And Attention Management standard

Menu button

Provide a named button that controls a menu of actions or links, exposes expanded state, moves focus into the menu, supports composite keyboard navigation, activates one command at a time, and returns focus to the trigger on close.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A local object or toolbar has three to eight secondary commands.
  • Commands are contextual and do not require search to find.
  • Visible primary actions should remain uncluttered while lower-priority commands stay reachable.
  • A named trigger can accurately describe the menu's scope.

Avoid when

  • The job is choosing a form value, selecting several values, or browsing a long list.
  • The command set is broad enough to require search, ranking, shortcuts, or cross-product scope.
  • The action is primary, time-critical, or safety-critical and should be visible.
  • The popup needs forms, rich previews, editable content, or multi-step review.
  • The implementation cannot provide reliable focus management and keyboard navigation.

Problem it prevents

Users need access to a short set of contextual commands, but showing every secondary action as a visible button crowds the interface and hiding commands behind unnamed popups breaks predictability.

Pattern anatomy

What a strong implementation has to make clear

User need

An object, row, card, toolbar, or header has more actions than should be visible at once.

Pattern promise

Provide a named button that controls a menu of actions or links, exposes expanded state, moves focus into the menu, supports composite keyboard navigation, activates one command at a time, and returns focus to the trigger on close.

Required state

Closed trigger state with visible or accessible name.

Recovery path

Screen readers hear button More with no object or scope, so users cannot tell which actions will appear.

Access contract

Use an actual button for the trigger when possible.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A table row has a Report actions button that opens a compact menu with Open, Rename, Duplicate, Archive, and an unavailable Export item.
  • A toolbar has a More actions button with secondary commands grouped after visible primary actions and a separator before destructive commands.
  • A user opens Report actions, arrows to Duplicate report, activates it, and focus returns to the Report actions trigger with a status update.
  • A user arrows to Archive report and the menu closes into a confirmation flow instead of archiving directly.
Weak implementation

Vague, hidden, hard to recover from

  • An unlabeled ellipsis opens a loose panel of buttons, inputs, links, toggles, and destructive commands with no active item.
  • A primary Save action is hidden behind More while lower-priority icons remain visible.
  • A user tabs into a menu and lands in a text input because the menu contains unrelated form controls.
  • A user hovers over an ellipsis, the panel opens visually, but keyboard users cannot reach the first item or dismiss it with Escape.
UI guidance
  • Render a named button trigger, visible opened state, controlled popup, menu items, active item styling, disabled item state, separator or section grouping, and a safe way to distinguish destructive commands.
  • Keep menu items as clear verbs or destinations, keep the menu compact, and avoid placing arbitrary forms, long content, nested page layouts, or primary task completion inside the popup.
UX guidance
  • Use a menu button when users need to reveal a short contextual set of commands or links from a single trigger without leaving the current object or toolbar context.
  • Make dismissal, activation, focus return, unavailable actions, and high-risk command handoff predictable so the menu behaves like a command chooser rather than a hidden form.
Implementation contract

What the implementation must handle

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.

Interaction

  • 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.

Accessibility

  • Use an actual button for the trigger when possible.
  • Set aria-haspopup to menu or true and keep aria-expanded synchronized with the visible menu state.
  • Use aria-controls when the controlled menu has a stable element ID.
  • Label the menu by the trigger or another clear accessible name.

Review

  • 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?
Interactive lab

Inspect the states before you copy the pattern

Open a contextual action menu

Open the menu, move between menu items, activate a safe item, dismiss with Escape, and inspect focus return plus destructive-action handoff.

Menu button
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Closed trigger state with visible or accessible name.

Keyboard / Access

Enter or Space on the trigger opens the menu and focuses the first menu item.

Avoid Generating

Using a menu button for long value selection that should be a select, listbox, combobox, or multi-select.
Evidence trail

Source-backed claims behind this guidance

WAI-ARIA APG Menu Button Pattern

W3C Web Accessibility Initiative - checked

APG defines menu button trigger semantics, aria-haspopup, aria-expanded, optional aria-controls, role menu popup, and trigger keyboard behavior.

WAI-ARIA APG Menu and Menubar Pattern

W3C WAI - checked

APG defines menu focus movement, item roles, disabled items, separators, Enter and Space activation, Escape dismissal, focus return, and roving focus or aria-activedescendant.

MDN ARIA menu role

MDN Web Docs - checked

MDN documents the menu role as a composite command widget with menuitem descendants, focus management, labeling, disabled state, and keyboard expectations.

Adobe Spectrum Menu

Adobe Spectrum - checked

Spectrum documents menu anatomy, trigger relationship, item labels, descriptions, disabled and unavailable states, sections, keyboard focus, text wrapping, and keyboard interactions.

Full agent/debug reference

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?
Accessibility
  • Use an actual button for the trigger when possible.
  • Set aria-haspopup to menu or true and keep aria-expanded synchronized with the visible menu state.
  • Use aria-controls when the controlled menu has a stable element ID.
  • Label the menu by the trigger or another clear accessible name.
  • Use role menu only when the popup behaves as an ARIA menu; otherwise prefer normal buttons, links, disclosure, or dialog semantics.
  • Use role menuitem, menuitemcheckbox, or menuitemradio for items and aria-disabled for unavailable items.
  • Manage focus with roving tabindex or aria-activedescendant and ensure the visual active item matches the accessibility tree.
  • Return focus to the trigger on Escape, close, and completed activation.
  • Keep labels, disabled reasons, destructive consequences, shortcuts, and section meaning available to screen reader users.
Keyboard Behavior
  • Enter or Space on the trigger opens the menu and focuses the first menu item.
  • Down Arrow on the trigger may open the menu and focus the first item.
  • Up Arrow on the trigger may open the menu and focus the last item.
  • Down Arrow in the menu moves to the next item, optionally wrapping.
  • Up Arrow in the menu moves to the previous item, optionally wrapping.
  • Home and End move to the first and last item when implemented.
  • Printable character keys may move to the next item whose label starts with that character.
  • Enter or Space activates the active item unless the item is disabled.
  • Escape closes the menu and returns focus to the trigger.
  • Tab closes the menu and moves focus to the next focusable page element.
Variants
  • Text menu button
  • Icon menu button with accessible name
  • Overflow menu button
  • Split button with adjacent menu trigger
  • Navigation menu button
  • Context menu trigger
  • Menu button with menuitemcheckbox
  • Menu button with menuitemradio
  • Menu button with grouped sections

Verification

Last verified: