Menu button: “More actions” that works with keyboard + screen readers

Live demo: menu-button-demo.html (BEFORE/AFTER)

This shows a “looks like a menu” popup that fails basic keyboard expectations, and a safer menu button pattern.

What breaks in many “More actions” popups

The popup is visually a menu, but has no menu semantics (screen readers won’t announce it as a menu).
There’s no Escape to close.
Focus stays on the button, so keyboard users must Tab around and can fall into background UI.
Closing doesn’t restore focus to the trigger (users “lose their place”).

Minimum viable pattern

Trigger button
- aria-haspopup="menu"
- aria-expanded reflects open/closed
- aria-controls references the popup
Popup
- role="menu" with a clear label
- each action is role="menuitem"
Focus management
- On open: move focus into the menu (usually first item; if opened with ↑, focus last item).
- On close: restore focus to the trigger button.
Keyboard behavior
- ↓/↑ moves between items
- Home/End jumps
- Enter/Space activates
- Esc closes

One caution: don’t overuse role=menu

ARIA menus are optimized for application-style menus (like desktop app menus). For a simple list of links, a normal list of links/buttons may be more appropriate.

If you do choose a menu: make its keyboard behavior predictable. If you can’t commit to Arrow-key navigation + Escape + focus restoration, don’t call it a menu.

Next step: add typeahead (optional) and close-on-outside-click for pointer users, while keeping focus restoration for keyboard users.