Menubar

Demo & usage

More examples

When to use

• An application shell that needs File / Edit / View — an editor, an IDE-like tool, a design surface.
• A dense toolbar where the same commands need keyboard access and a discoverable home.
• For a single button that drops a list of actions, use Dropdown Menu. For right-click, use Context Menu.

Async states

None — this component has nothing to load, so it has no loading, empty or error state to drive.

Outputs

Customization & theming

• Feed `menus` with either flat `items` or `groups` per menu — the same item shape Dropdown Menu takes, including icons, shortcuts, badges, dividers, checkbox/radio types and `danger`.
• `size` sets the bar's own density; `menuSize` is passed through to the panels.
• Two-way bind `[(openMenuId)]` to open a menu from a shortcut of your own or close everything on navigation.
• `disabled` on the bar or on a single menu; disabled menus are skipped by the arrow keys rather than focused and refused.
• Shortcuts it actually owns: an item's `keys` (`'mod+n'`) renders itself for the running platform, and `[registerShortcuts]` binds it through the shared registry, where `[shortcutScope]` decides whether an overlay's binding outranks it. Duplicates are reported through `(shortcutConflicts)` whether or not anything is bound. Off by default, because an app with a menubar has usually bound these keys already.

Best practices

• Do: Keep top-level labels to one word — they are targets on a shared row, and the first letter is the type-ahead key.
• Do: Give every item `keys` (e.g. `'mod+n'`) rather than a `shortcut` glyph string — the menu bar is where users go to LEARN shortcuts, and `keys` renders itself as ⌘N or Ctrl N for the platform they are actually on. `shortcut` is display-only, binds nothing, and shows ⌘N to a Windows user exactly as typed.
• Do: Turn on `[registerShortcuts]` if the app does not already bind these keys itself, so the bar arbitrates what it draws instead of just drawing it. Duplicate `keys` are reported through `(shortcutConflicts)` either way — two items both claiming ⌘N is a bug in the menu definition, and only one of them could ever run.
• Do: Set `keepOpen` on checkbox items so a run of toggles does not slam the menu shut on the first one.
• Don't: Don't use it as navigation — a menubar announces itself as commands, not as links: items are reached by arrow keys instead of Tab and are missing from a screen reader's links list. Use Mega Menu or a nav bar inside a `<nav>` for going places. In dev mode the bar warns when any item has an `href`.
• Don't: Don't reach for a menubar to expose one or two actions — it is a commitment to an application keyboard model (roving tabindex, type-ahead, cross-menu arrows). Two buttons are two buttons.

Accessibility

• A real `role="menubar"` owning `role="menuitem"` buttons — the Dropdown Menu trigger wrapper is made presentational so the ownership assistive technology walks is not broken by a layout div.
• ONE tab stop for the whole bar via a roving tabindex; Left/Right move between menus (wrapping, skipping disabled), Home/End jump to the ends, Down/Enter/Space open, Escape closes and returns focus to the trigger.
• With a menu open, moving along the bar carries the open menu with it — and the keys the open panel owns (Up/Down, Enter, type-ahead over items) are left to the panel rather than handled twice.
• The panel keeps DOM focus on the trigger and moves a virtual cursor, so `aria-activedescendant` and `aria-owns` are published from the trigger button — the element that actually has focus.