Menu / menubar

Problem Context

• The product behaves like an application or editor with many stable commands.
• Commands need grouping by intent such as file operations, editing, viewing, insertion, formatting, or tools.
• Users benefit from seeing command categories persistently while the submenu content stays compact.
• Some commands are unavailable, checked, or open nested submenus depending on current context.
• Keyboard users need a desktop-style interaction model that does not require tabbing through every submenu item from the page.

Selection Rules

• Choose a menu or menubar when the interface has a stable, application-like command hierarchy that users revisit frequently.
• Use a menu button when a single local trigger reveals a short command list for one object, row, or toolbar.
• Use command palette when commands need search, ranking, fuzzy matching, recents, or cross-product discovery.
• Use global navigation, tabs, side navigation, or mega menu when the primary job is choosing destinations rather than invoking commands.
• Use select, listbox, radio group, checkbox group, or multi-select when the user is choosing values for data, filters, or preferences rather than executing commands.
• Use menuitemcheckbox or menuitemradio for command state that belongs inside the menu, not a nested checkbox, toggle, or radio control.
• Keep disabled commands visible when their existence matters, expose aria-disabled, and do not allow activation.
• Avoid ARIA menu and menubar roles unless the implementation supports the full composite keyboard model.

Required States

• Persistent closed menubar state with labelled top-level command groups.
• Focused top-level menuitem state.
• Open submenu state connected to its parent menuitem with aria-haspopup and aria-expanded.
• Focused submenu item state.
• Nested submenu open state with parent item focus return.
• Activated command state with menu closed and focus returned to the invoking context.
• Checked menuitemcheckbox or menuitemradio state.
• Disabled but focusable menu item state.
• Separator or group state for command sections.
• Typeahead, Home, and End movement state.
• Escape dismissed state.
• Tab exit state with all menus closed.
• Horizontal and vertical orientation states where applicable.

Interaction Contract

• The persistent bar has role menubar and a visible label or accessible name.
• Top-level command items use menuitem, menuitemcheckbox, or menuitemradio roles and are managed with roving tabindex or aria-activedescendant.
• A parent menuitem with a submenu exposes aria-haspopup and synchronized aria-expanded state.
• Submenus use role menu and are labelled by or otherwise connected to the parent item that opened them.
• Right and Left Arrow move between top-level items in a horizontal menubar; Down and Up Arrow open or move inside vertical submenus.
• Enter or Space activates a command, toggles checked state, or opens a submenu according to the item role.
• Escape closes the current menu and returns focus to the parent menuitem, menubar item, or invoking context.
• Tab exits the composite widget and closes open menus rather than moving through every hidden command.
• Disabled menu items remain focusable when following the application-menu model but cannot activate.
• Hidden submenus are not reachable by keyboard or assistive technology while closed.

Implementation Checklist

• Confirm this is an application command system, not ordinary navigation or a one-off overflow menu.
• Inventory command groups and keep top-level labels stable, short, and task-recognizable.
• Use role menubar for the persistent command bar and role menu for submenus only when implementing composite keyboard behavior.
• Implement roving tabindex or aria-activedescendant so one item owns focus at a time.
• Expose aria-haspopup and aria-expanded on items that open submenus and aria-checked on checkable menu items.
• Implement Right, Left, Down, Up, Home, End, printable-character typeahead, Enter, Space, Escape, and Tab exit behavior.
• Keep disabled commands visible when they teach availability, expose aria-disabled, and prevent activation.
• Use separators and groups to keep command sections scannable without creating focus stops.
• Test nested submenus, screen reader announcements, shortcut conflicts, high zoom, forced colors, pointer hover, touch fallback, route changes, and focus return to the editing context.

Common Generated-UI Mistakes

• Using role menubar for a normal website header or product navigation row.
• Using a menubar when one menu button or visible toolbar actions would be simpler.
• Putting form controls, sliders, date pickers, editable fields, or arbitrary cards inside menuitem rows.
• Leaving hidden submenu items in the tab order.
• Letting aria-expanded drift away from the visible submenu state.
• Making disabled commands unfocusable or invisible when users need to understand unavailable capabilities.
• Using hover as the only way to open submenus.
• Overriding browser, operating-system, or assistive-technology shortcuts with custom menu shortcuts.

Critique Questions

• Is this truly a persistent application command system, or is it navigation, a toolbar, or a local overflow?
• Can users move between top-level command groups with Arrow keys without tabbing through every submenu item?
• Do checkable and disabled commands expose state through menu item semantics rather than nested controls?
• Does Escape close the correct level and return focus to the parent command or invoking context?
• Are hidden submenus removed from focus and screen reader reach while closed?