Accessible Menu & Menu Button Guide

The Most Over-Applied Role in ARIA

1. First, Decide: Menu, Disclosure, or Plain List?

Three different patterns produce a button that reveals a dropdown. Picking the wrong one is the root cause of nearly every broken menu, so make this decision before you write a line of markup.

The decision resembles the one between tabs and an accordion: the pattern you choose is a promise about how the keyboard will behave. Choose the one whose promise matches what your component actually is, then keep that promise exactly.

3. Roving Tabindex: How Focus Moves Inside a Menu

A menu is a composite widget, which means the entire menu occupies one stop in the page tab sequence and the arrow keys move within it. The technique that delivers this is roving tabindex, and the menu is its canonical example.

Menus use roving tabindex because there is no text field to protect: moving real focus is simpler, and it means document.activeElement always tells you the truth about where the user is. The consequence to remember is that tabindex="-1" makes an element focusable by script but skipped by Tab — that is the whole trick. The focus management guide covers the technique in depth, including focus restoration, which a menu depends on when it closes.

5. The Keyboard Model You Must Implement

Choosing role="menu" is a promise that these keys work. Users of screen readers and keyboard-only users recognise the pattern from operating-system menus and will expect every row of this table.

The two rows people skip are Escape and Tab, and they are the two that keep you clear of 2.1.2 No Keyboard Trap. A user must always have a way out of an open menu without activating anything in it. For the broader keyboard contract every custom widget owes, see the keyboard accessibility guide.

7. Checkable Items: Toggles and One-of-Many Choices

Menus frequently carry state — a sort order, a set of visible columns, a density setting. ARIA has two roles for this, and the distinction is the same as between an HTML checkbox and a radio group.

<ul id="view-menu" role="menu" aria-labelledby="view-button">
  <!-- Independent toggles: any combination may be checked. -->
  <li role="menuitemcheckbox" aria-checked="true" tabindex="0">
    Show archived
  </li>
  <li role="menuitemcheckbox" aria-checked="false" tabindex="-1">
    Show drafts
  </li>

  <li role="separator"></li>

  <!-- One-of-many: the group needs its own accessible name. -->
  <li role="group" aria-label="Sort by">
    <ul role="none">
      <li role="menuitemradio" aria-checked="true" tabindex="-1">Date</li>
      <li role="menuitemradio" aria-checked="false" tabindex="-1">Name</li>
      <li role="menuitemradio" aria-checked="false" tabindex="-1">Size</li>
    </ul>
  </li>
</ul>

Activating a menuitemcheckbox flips its aria-checked and, by convention, leaves the menu open so the user can set several options at once. Activating a menuitemradio sets it to true, sets its siblings to false, and usually closes the menu since the choice is complete. Never convey the checked state with a tick icon alone — the icon is invisible to a screen reader, and aria-checked is what actually gets announced. The role="none" on the inner list removes its list semantics so it does not interrupt the menu structure.

9. Menus in React

React changes nothing about the roles or the keyboard model, but it does change where the hard parts live. Focus has to be moved imperatively through refs after render, and the menu must be positioned so it never opens off screen. Here is the shape of a hand-rolled version:

function ActionsMenu({ items }) {
  const [open, setOpen] = useState(false)
  const [activeIndex, setActiveIndex] = useState(0)
  const buttonRef = useRef(null)
  const itemRefs = useRef([])
  const menuId = useId()

  // Move real DOM focus whenever the active item changes.
  useEffect(() => {
    if (open) itemRefs.current[activeIndex]?.focus()
  }, [open, activeIndex])

  function close({ returnFocus = true } = {}) {
    setOpen(false)
    if (returnFocus) buttonRef.current?.focus()
  }

  function onMenuKeyDown(event) {
    if (event.key === "ArrowDown") {
      event.preventDefault()
      setActiveIndex((i) => (i + 1) % items.length)
    } else if (event.key === "ArrowUp") {
      event.preventDefault()
      setActiveIndex((i) => (i - 1 + items.length) % items.length)
    } else if (event.key === "Escape") {
      close()
    } else if (event.key === "Tab") {
      close({ returnFocus: false })
    }
  }

  return (
    <>
      <button
        ref={buttonRef}
        aria-haspopup="menu"
        aria-expanded={open}
        aria-controls={menuId}
        onClick={() => { setActiveIndex(0); setOpen((o) => !o) }}
      >
        Actions
      </button>

      {open && (
        <ul id={menuId} role="menu" onKeyDown={onMenuKeyDown}>
          {items.map((item, i) => (
            <li
              key={item.id}
              role="menuitem"
              ref={(el) => { itemRefs.current[i] = el }}
              tabIndex={i === activeIndex ? 0 : -1}
              onClick={() => { item.onSelect(); close() }}
            >
              {item.label}
            </li>
          ))}
        </ul>
      )}
    </>
  )
}

That covers the mechanics, but it is not what you should ship. Production menus also need collision-aware positioning, portal rendering so the menu escapes overflow: hidden, click-outside handling, typeahead, and submenu timing. Radix DropdownMenu, React Aria's useMenu, and Headless UI's Menu all implement the full pattern and keep pace with ARIA guidance. See the React accessibility guide for how these primitives fit into a component library, and the Vue and Angular guides for their equivalents — Angular's FocusKeyManager in particular exists to implement exactly this roving-tabindex behavior.

How to Test an Accessible Menu

Automated tools catch a missing aria-expanded or an aria-controls that points at nothing. Everything that actually matters about a menu — where focus goes, whether you can escape — needs six minutes of manual testing.

1. Put the mouse away. Tab to the button, press Enter, and confirm the menu opens and that focus lands on the first item.
2. Arrow through every item. Focus should move visibly, wrap or stop consistently, and never scroll the page behind the menu.
3. Press Escape. The menu closes and focus is back on the button — not on <body>, and not at the top of the page.
4. Press Tab from inside. The menu closes and focus continues to the next element after the button. Tab should never step through items one by one.
5. Count the tab stops. With the menu closed, Tab past it. The whole component should cost exactly one stop.
6. Listen with a screen reader. You should hear the button's name, “menu pop-up,” the collapsed or expanded state, and then each item with its position. Use the screen reader testing guide for the commands.
7. Check the links list. If the dropdown holds navigation, open the screen reader's links list. Missing entries mean role="menuitem" has eaten your link semantics.

Layer automated checks on top with axe-core, and see automated vs manual testing for where each fits. Scan the live page with the URL accessibility auditor.

Accessible Menu Checklist

1. Right pattern. The items are commands, not links. If they navigate, it is a disclosure with a <nav> of links instead.
2. Real button. A native <button> with aria-haspopup="menu", aria-expanded that updates, and aria-controls.
3. Clean menu contents. role="menu" holds only menu items, groups, and separators — no headings, forms, or prose.
4. One tab stop. Roving tabindex — one item at 0, the rest at -1 — with arrow keys moving focus.
5. Focus moves and returns. Opening focuses the first item; Escape closes and restores focus to the button.
6. Tab escapes. Tab closes the menu and continues through the page, satisfying 2.1.2.
7. State is announced. Checkable items carry aria-checked, never a tick icon alone.
8. Visible focus, adequate targets. A clear focus indicator on the active item, and items at least 24 by 24 CSS pixels (2.5.8).

Work through the full WCAG 2.2 checklist to see the menu in the context of every other requirement.

Frequently Asked Questions