UX Patterns Guide
UI + UX Selection And Choice established

Action menu

Design the action menu as a scoped command list: name the resource or selection, group related commands, label each item by verb and object, explain unavailable actions, separate high-risk commands, and route consequential actions through review or recovery.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A resource, row, card, selected set, or local page object has several contextual commands.
  • The commands are important enough to remain discoverable but not important enough to all stay visible.
  • Menu content needs grouping, disabled reasons, destructive separation, or scope-sensitive labels.
  • The same trigger or action surface appears across repeated objects and item labels need object context.

Avoid when

  • Only one or two commands are needed and visible buttons would be faster.
  • The command set is broad enough to need search, ranking, recents, or keyboard shortcuts across the product.
  • Users are choosing a value, filter, mode, or form answer rather than invoking a command.
  • The menu would contain forms, long explanations, previews, editable fields, or multi-step review.
  • The action is primary, urgent, or safety-critical and should be visible instead of hidden.

Problem it prevents

Contextual commands often need to stay compact, but generic overflow menus become junk drawers when they mix unrelated actions, hide scope, omit disabled reasons, and place destructive commands beside safe actions.

Pattern anatomy

What a strong implementation has to make clear

User need

A row, card, table, selected set, page resource, or toolbar has more contextual commands than should be visible at once.

Pattern promise

Design the action menu as a scoped command list: name the resource or selection, group related commands, label each item by verb and object, explain unavailable actions, separate high-risk commands, and route consequential actions through review or recovery.

Required state

Closed trigger or contextual entry point with resource scope.

Recovery path

A repeated ellipsis menu has no object name, so assistive technology users hear identical Actions buttons in every row.

Access contract

Give the trigger or menu an accessible name that includes the resource or selected-set scope.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A Customer actions menu has Manage customer, Data requests, and Account risk sections, with Edit customer, Merge customer, Request data export, and Delete customer separated at the end.
  • A bulk selection menu changes labels from Archive customer to Archive 3 customers and disables Merge because it only applies to one customer.
  • A user opens Customer actions, chooses Duplicate customer, and receives status that names the customer and keeps focus anchored to the action context.
  • A user changes from one selected customer to three, sees single-object actions disabled with reasons, and can run Export selected customers.
Weak implementation

Vague, hidden, hard to recover from

  • A More menu contains Open, Edit, View, Delete, Settings, Filter, Owner, and a search box with no sections or object names.
  • A Delete action sits between Rename and Duplicate with the same style and no consequence preview.
  • A user chooses Delete from a generic row menu and cannot tell whether it deletes the row, account, attached files, or selected customers.
  • A user opens a menu to export selected items but the action is disabled with no reason or next step.
UI guidance
  • Render a compact menu of verb-led actions scoped to one resource, row, card, selected set, or page object, with clear section headings, object-aware labels, disabled reasons, and separated dangerous commands.
  • Use icons, shortcuts, descriptions, and external-link markers only to clarify text labels; avoid making the menu a mixed panel of forms, filters, field values, navigation, and unrelated controls.
UX guidance
  • Use an action menu when users need several contextual commands without keeping every command visible, and the list itself must explain scope, availability, risk, and outcome.
  • Make the current object or selection count explicit, update actions when scope changes, and route destructive or privacy-sensitive commands into confirmation, undo, restore, or review instead of running silently.
Implementation contract

What the implementation must handle

States

  • Closed trigger or contextual entry point with resource scope.
  • Open menu with accessible name that includes the object or selection scope.
  • Sectioned menu state with headings or separators.
  • Safe command item state with verb and object label.

Interaction

  • Every item has a clear verb, object, and outcome category: command, navigation link, checkable command, disabled command, or destructive command.
  • The menu title, trigger label, aria-label, or nearby context identifies which resource or selected set the actions affect.
  • Sections group commands by user intent or risk, not by implementation owner.
  • Disabled actions cannot run and explain the blocker when users need that knowledge.

Accessibility

  • Give the trigger or menu an accessible name that includes the resource or selected-set scope.
  • Use menuitem roles only when implementing the menu keyboard model; otherwise use semantic buttons and links inside an appropriate popup or sheet.
  • Keep visible labels and accessible names aligned, especially in repeated row menus.
  • Expose disabled actions with aria-disabled or native disabled behavior according to the implementation, and provide the reason in visible or programmatic text.

Review

  • Can users tell exactly which object or selected set the menu will affect?
  • Are commands grouped by meaningful user intent and risk rather than dumped into one list?
  • Do item labels name the action and object well enough for repeated row menus?
  • Are disabled actions either explained or omitted according to whether the user can recover?
Interactive lab

Inspect the states before you copy the pattern

Operate on a scoped action list

Switch from one customer to three selected customers, inspect the grouped menu, try the disabled export, run a safe action, and send Delete to review.

Action menu
Loading interactive demo...

State To Inspect

Closed trigger or contextual entry point with resource scope.

Keyboard / Access

Opening and closing follow the menu-button, context-menu, action-sheet, or platform trigger pattern used by the surface.

Avoid Generating

Treating the action menu as a junk drawer for every command that does not fit elsewhere.
Evidence trail

Source-backed claims behind this guidance

Shopify Polaris Menu

Shopify - checked

Shopify documents contextual resource action menus with accessible labels, grouped sections, disabled items, links, icons, keyboard navigation, and critical delete actions.

Adobe Spectrum Menu

Adobe Spectrum - checked

Spectrum documents menu anatomy, item labels, descriptions, values, unavailable and disabled states, sections, dividers, checkable selection states, keyboard focus, text wrapping, and keyboard interactions.

WAI-ARIA APG Menu and Menubar Pattern

W3C WAI - checked

APG defines menu roles, menuitem roles, composite focus, keyboard movement, disabled items, separators, activation, dismissal, and focus return for action-oriented menus.

Atlassian Design System Dropdown menu

Atlassian Design System - checked

Atlassian defines dropdown menus as lists of actions or options and distinguishes item types for actions, checkbox items, radio items, and popup layering.

Full agent/debug reference

Problem Context

  • A row, card, table, selected set, page resource, or toolbar has more contextual commands than should be visible at once.
  • The command list changes according to object state, permissions, processing state, or selection count.
  • Users need to distinguish safe commands, links, disabled commands, bulk actions, and dangerous commands before activation.
  • The trigger pattern already exists, but the menu content still needs taxonomy, labels, grouping, state, and outcome rules.
  • The interaction must work for pointer, keyboard, touch, and assistive technology users without losing object context.

Selection Rules

  • Choose an action menu when commands are contextual to one object, selected set, resource, row, card, or local page surface.
  • Use a menu button pattern when the primary problem is trigger labelling, open state, popup ownership, focus movement, dismissal, and focus return.
  • Use a button group when there are only a few important related commands that should remain visible.
  • Use a command palette when commands are broad, searchable, shortcut-driven, cross-product, or not tied to the current object.
  • Use a menubar when the product has a persistent application command hierarchy with stable top-level command groups.
  • Use select, listbox, radio group, checkbox group, multi-select, or chip selection when the user is choosing values rather than invoking commands.
  • Use confirmation dialog, typed confirmation, undo, or restore after a dangerous action is selected, not as a substitute for clear menu item labels.
  • Use action sheet, context menu, drawer, or bottom sheet for platform-specific presentation when the same contextual command-list rules apply.

Required States

  • Closed trigger or contextual entry point with resource scope.
  • Open menu with accessible name that includes the object or selection scope.
  • Sectioned menu state with headings or separators.
  • Safe command item state with verb and object label.
  • Disabled or unavailable command state with visible reason.
  • External link or navigation item state when links are allowed.
  • Destructive command state separated from safe commands.
  • Bulk selection state that updates labels, disabled rules, and result copy.
  • Processing or recently completed command status.
  • Dangerous command review handoff state.
  • Empty or no-applicable-actions state.
  • Long label, narrow viewport, and high-zoom wrapping state.

Interaction Contract

  • Every item has a clear verb, object, and outcome category: command, navigation link, checkable command, disabled command, or destructive command.
  • The menu title, trigger label, aria-label, or nearby context identifies which resource or selected set the actions affect.
  • Sections group commands by user intent or risk, not by implementation owner.
  • Disabled actions cannot run and explain the blocker when users need that knowledge.
  • Bulk selection changes item labels, disabled state, and result status so commands cannot silently affect the wrong scope.
  • Dangerous commands are visually separated and either open review, confirmation, undo, restore, or another recovery path.
  • Links disclose navigation or new-tab behavior when they can leave the current task.
  • The menu closes after safe command activation and reports what changed.
  • Focus return, keyboard movement, and dismissal follow the trigger pattern or platform action-sheet behavior.
  • The compact action menu does not contain forms, complex editors, large previews, filters, or unrelated content.

Implementation Checklist

  • Inventory commands by resource state, permission, selected count, frequency, risk, and recovery path.
  • Name the menu by object or scope, such as Customer actions or Actions for 3 selected invoices.
  • Write each item as a verb phrase with enough object context for repeated rows and screen readers.
  • Group related commands under headings or separators when there are different scopes or risk levels.
  • Separate destructive actions and define confirmation, undo, restore, or review behavior before implementation.
  • Decide when unavailable actions should remain visible with a reason versus be omitted because they never apply.
  • Update the menu when selection count, object state, permission, processing, or ownership changes.
  • Keep icons optional, consistent, and secondary to text; give icon-only triggers precise accessible names.
  • Avoid embedding form controls, search boxes, sliders, calendars, rich previews, and editable tables inside the action menu.
  • Test row context, bulk context, disabled reasons, destructive handoff, keyboard focus, screen reader names, touch target size, zoom, forced colors, clipping, and portal placement.

Common Generated-UI Mistakes

  • Treating the action menu as a junk drawer for every command that does not fit elsewhere.
  • Using vague labels such as Open, Manage, More, or Delete without naming the object or result.
  • Mixing commands, links, field values, filters, toggles, and form fields without role or visual distinction.
  • Leaving disabled actions greyed out with no reason or recovery path.
  • Letting a bulk action menu run single-object commands against multiple selected items.
  • Putting destructive actions in the middle of safe commands with the same emphasis.
  • Hiding primary or emergency recovery commands inside a menu while low-value buttons stay visible.
  • Using icons as the only action names inside the menu.
  • Failing to update menu content after object state changes, such as archived, locked, processing, or permission-limited records.

Critique Questions

  • Can users tell exactly which object or selected set the menu will affect?
  • Are commands grouped by meaningful user intent and risk rather than dumped into one list?
  • Do item labels name the action and object well enough for repeated row menus?
  • Are disabled actions either explained or omitted according to whether the user can recover?
  • Does the menu update when selection count, permission, processing state, or ownership changes?
  • Are destructive commands separated and routed through confirmation, undo, restore, or review?
  • Is any menu content actually a form, filter panel, settings page, or value selector that needs a different pattern?
Accessibility
  • Give the trigger or menu an accessible name that includes the resource or selected-set scope.
  • Use menuitem roles only when implementing the menu keyboard model; otherwise use semantic buttons and links inside an appropriate popup or sheet.
  • Keep visible labels and accessible names aligned, especially in repeated row menus.
  • Expose disabled actions with aria-disabled or native disabled behavior according to the implementation, and provide the reason in visible or programmatic text.
  • Expose checkable command state with menuitemcheckbox or menuitemradio only when the menu item is a persistent command state.
  • Use separators and groups semantically without creating unnecessary focus stops.
  • Keep destructive labels, consequences, and confirmation or recovery paths available to screen reader users.
  • Do not rely on icons, color, or position alone to communicate item role, risk, checked state, or disabled state.
Keyboard Behavior
  • Opening and closing follow the menu-button, context-menu, action-sheet, or platform trigger pattern used by the surface.
  • Arrow keys move between menu items when using ARIA menu semantics.
  • Enter or Space activates the focused command unless it is disabled.
  • Escape closes the menu or action sheet without running a command.
  • Tab exits or dismisses according to the chosen popup pattern and does not reach hidden menu items.
  • After safe activation, focus returns to the trigger, affected row, result status, or next logical workflow target.
  • After destructive selection, focus moves to confirmation or review with the affected object named.
  • Bulk selection changes should be announced through the trigger label, menu label, or nearby selection status.
Variants
  • Row action menu
  • Card action menu
  • Page resource action menu
  • Bulk action menu
  • Account actions menu
  • Data request action menu
  • Danger-separated action menu
  • Action menu with disabled reasons
  • Action menu with external links
  • Action sheet presentation
  • Context menu presentation

Verification

Last verified: