Menu

Transient surfaces that hold actions or detail. Both hide things behind a click, which is fine for the secondary and never acceptable for the urgent.

Overview

A menu holds actions. A popover holds content. A split button is a primary action with a menu of alternatives attached, and a menu button is a menu with no default. All four share one property that governs everything below: they are closed most of the time.

Anatomy

Rules

• Never hide a primary action in a menu. The screen's main action is on the screen — see Button.
• Never put an alarm or a finding in either. Clinical signals are persistent and cannot live behind a click — see Alert Banner.
• Destructive items sit below a separator, last, and never adjacent to a routine action.
• Menu items are actions, not navigation. Places belong in Navigation; a menu that navigates loses the back button.
• No submenus. If a menu needs nesting it is a panel or a screen.
• Disabled items say why, inline — the same rule as Interaction states.
• Popovers close on outside click and on Esc, and never contain a form that submits. That is a Dialog.
• Repositions to stay clear of the alert region rather than overlapping it — see Elevation.

What may be inside

A menu holds actions. The moment it holds anything a clinician has to fill in, decide between, or read carefully, it has become a dialog wearing a menu's clothes — and it has none of a dialog's protections.

• Every item is a verb. "Export report", "Compare with prior". An item that reads as a noun is usually a destination, and destinations belong in Navigation.
• Secondary text carries why an item is unavailable, or a keyboard shortcut — never a description. "Re-analyse · needs a new ECG" tells the reader something the label cannot. A second line explaining what the action does means the label failed.
• A shortcut shown in a menu works. Printing an accelerator that does nothing on this platform, or that a deployment has rebound, teaches the reader to distrust every other one.
• Beyond about eight items, the menu is the wrong shape. Systems commonly cap at fifteen and add a scrollbar; a scrolling menu is a panel that has not admitted it, and fifteen actions on one object is a design problem rather than a layout one. Group them onto a surface that can stay open.
• Disabled items stay, with their reason. Removing an unavailable action changes the set of things the reader believes exist — the same argument as a locked row in List.

Where it opens, and what it may cover

A menu is positioned relative to its trigger and flips to stay on screen. Two things it must never end up on top of.

• Never the alert region. Already the rule above, restated because automatic flipping is exactly how a menu ends up somewhere nobody chose — the flip logic knows about the viewport and not about the alarm layer, so the constraint has to be given to it explicitly.
• Never the row it acts on. A menu opened from a patient row that covers that row leaves the clinician choosing an action for a patient they can no longer see. It opens beside or below, and if there is no room for both, the row stays visible and the menu moves.
• The subject is named in the menu itself where the menu acts on one — a header reading "HARLAND, A. · MRN 44 812 907". A menu floating free of its context is how the right action reaches the wrong record, and it costs one line.
• It does not reposition while open. Content arriving behind it must not cause it to jump under a finger already moving — see Reprioritisation.

Opening and closing

• Focus moves to the first item on open, and arrow keys move between items — a menu is a composite widget, unlike an accordion.
• Escape closes it and returns focus to the trigger. Returning focus is the half that gets skipped: without it, Escape leaves a keyboard user at the top of the document with no way back to where they were.
• Closing is never destructive. Since a menu holds only actions, closing one can discard nothing — which is the same reason form controls are refused above.
• An outside click closes it and does nothing else. The click that dismisses a menu never also activates whatever was underneath.

Why there is no Popover

This page was titled “Menu & popover” for a long time, its sidebar entry said so until today, and its accessibility section credited a Radix Popover primitive. There has never been a Popover in this package. That is worth deciding out loud rather than quietly correcting, because it is the most obvious control this system does not have.

What a popover is usually reached for, and what to use instead:

The pattern underneath is the one this page and Select both end on: a transient surface accumulates features because it is convenient to put them there, and each addition costs a protection the surface was never designed to provide. A component whose only definition is “floating” has no grounds to refuse any of them.

What the component enforces, and what it only asks for

The surface holds its own keyboard and dismissal. What it refuses to hold is content, and that refusal is the point.

Do's and don'ts

Accessibility

• Hand-written, not a primitive library. This line credited “Radix Menu and Popover primitives” for roles, focus trapping, outside dismissal and return focus. There is no Radix anywhere in this package, there is no Popover in it at all, and the focus-on-open and arrow-key handling this component does have were written by hand after a gate found they were missing. The same line claimed type-ahead, which is not implemented — and which Select argues is a hazard rather than a convenience.
• Trigger carries aria-haspopup and aria-expanded; the surface is labelled by its trigger.
• Arrow keys move between menu items, Home and End jump to the ends, type-ahead moves focus to the next item starting with the letter and selects nothing, Esc closes and returns focus.
• Split button is two controls with separate accessible names — "Export PDF" and "Other export formats" — not one control with a hidden second target.
• Items meet the physical touch floor, which on a cart means fewer visible at once — see Scaling.
• Never role="menu" for navigation. A list of links is a nav, and screen-reader users navigate them differently.

Outcomes of use

What this contributes to, in the terms of Usability & context of use. These are attributes believed to contribute to an outcome; the outcome itself is settled by observing real use in a specified context, not by this page.

• Effectiveness — the action taken is the one intended, and nothing needed is unreachable because it was hidden.
• Efficiency — secondary actions available without occupying screen space that clinical content needs.
• Satisfaction — confidence that nothing important is concealed. A clinician who opens every menu to check has been given the wrong container.

Clinical safety notes

• No alarm or finding inside a menu or popover. (the component) Mitigates: a clinical signal behind a click, invisible until sought.
• No primary action hidden. (you) Mitigates: delay in a time-critical pathway.
• Destructive items separated and last. (the component) Mitigates: irreversible action from a mis-tap on an adjacent item.
• Repositions clear of the alert region. (you) Mitigates: an open surface obscuring an active alarm.
• No submenus. (the component) Mitigates: structure that cannot be held under interruption or operated reliably by touch.
• Popovers never hold decision-relevant data. (the component; there is no popover) Mitigates: reliance information absent on touch surfaces and in print.

Implementation

$ npx shadcn@latest add https://md.notjustany.tech/r/menu.json

<Menu
  triggerLabel="More"
  subject="ECG acquired 14:26"      // what the actions will act on
  actions={[
    { id: "compare", label: "Compare with prior", onSelect: compare },
    { id: "reanalyse", label: "Re-analyse", disabled: true,
      note: "Needs a new ECG" },
    { id: "discard", label: "Discard draft report", onSelect: discard,
      destructive: true },
  ]}
/>

// 'actions' is data, not children, so an alarm or a finding cannot be placed
// inside the surface. Destructive items sort last.

Related

• Affordance & perceivability — why a right-click or an unlabelled icon is not a way to open this.
• Button — action hierarchy and destructive styling.
• Dialog — when a decision must be made before continuing.
• Tooltip — when a label is enough.
• Elevation — the popover layer.