fix(menus): a menu opened from the keyboard takes focus, and every menu answers the arrow keys

[MerciHanrim]

Problem

A menu opened from the keyboard does not take focus. Enter or Space on a menu button opens the menu and leaves focus on the button, so a screen reader announces that something opened and then reads nothing in it. In three of the menus the arrow keys then do nothing at all.

Found with Windows Narrator in Chrome while #306 was being checked. It is not caused by #306: every row below was measured on the build of main 0fbad79 (v0.14.0 · build 0fbad79), on that build's own deployment address, in a fresh browser profile, at 1280 px, in English.

Measured

Menu button	Enter / Space	Arrow Down on the closed button	Arrow Down once open	End once open	Escape
Templates	opens, focus stays on the button	does not open	first item	last item	closes, focus on the button
Insert module	opens, focus stays on the button	does not open	first item	last item	closes, focus on the button
File	opens, focus stays on the button	does not open	first item	last item	closes, focus on the button
Data	opens, focus stays on the button	does not open	nothing	nothing	closes, focus on the button
Settings	opens, focus stays on the button	does not open	nothing	nothing	closes, focus on the button
Help	opens, focus stays on the button	does not open	nothing	nothing	closes, focus on the button

• All six popups declare role="menu". The Settings popup declares it and holds no menuitem at all: its content is other controls.
• Templates, Insert module and File use the shared hook src/ui/useMenuKeyboard.ts. Data, Settings and Help do not. The hook's own comment says it was kept away from Help, Settings, the toolbar overflow, Data and the Distribution menu because nobody had specified their behaviour. This issue is that specification.
• Not measured at this width or state, and part of the audit below: the toolbar overflow (More actions), the Theme and Language controls inside Settings (each has its own arrow-key handling), and the export menu of the Distribution panel.
• Mobile, 390 px: the More sheet is a dialog named More with eleven button rows and no menu roles. Opening it from the keyboard puts focus on its Close button, and Escape closes it and returns focus to the More button. It has no aria-modal.

Not a defect

Narrator does not speak a menu item when the mouse pointer rests on it. A screen reader follows keyboard focus and its own cursor, not the pointer; reading under the pointer is a setting of the screen reader.

What the pattern asks

The W3C menu button pattern: Enter or Space opens the menu and places focus on the first item. Arrow Down on the button may open the menu and focus the first item, and Arrow Up the last. Inside the menu the arrow keys move, Home and End jump, and Escape closes and returns focus to the button. https://www.w3.org/WAI/ARIA/apg/patterns/menu-button/

Scope

One shared behaviour, audited across every menu. Not a patch for Insert module alone.

• Desktop: Templates, Insert module, File, Data, Settings, Help, the toolbar overflow, Theme, Language, and the Distribution panel's export menu.
• Mobile: the More sheet and every sheet it opens.
• For each one, decide what it is before giving it keys. A popup that declares role="menu" must behave as a menu. One that holds form controls and no menu items, as Settings does, is not a menu and should not say it is.
• The behaviour lives in the shared hook, with one owner for each key, as it does today for Escape.
• Opening with the mouse keeps working as it does now.

Done when

• A table like the one above, measured again on the fixed build, has no cell that disagrees with the contract chosen for that menu.
• Automated tests cover every menu in the scope: opening with Enter and with Space, where focus lands, the arrow keys, Home and End, Escape and the return of focus.
• A real screen reader has been used. Windows Narrator at least: for each menu, what was heard on opening and on moving through the items is written down. Platforms that were not checked are listed as not checked. A test that reads the accessibility tree is a structural check and is not called a screen-reader test.

Registered only. Not started.

[MerciHanrim]

Scope note: the Help menu is handled in #306, and the rest stays here.

Help is where the release notes are read again, which is what #306 adds, so its keyboard path could not wait for this audit. #306 changes that one menu and nothing else:

• opened with Enter or Space, focus goes to the first item; opened with the pointer, it stays on the button
• the arrow keys move and wrap, Home and End jump, separators are skipped
• Escape closes the menu once and returns focus to the Help button

The mechanism is one opt-in argument on the shared hook, enterOnOpen in src/ui/useMenuKeyboard.ts, set by a menu when its button was activated without a pointer. No other menu passes it yet, so Templates, Insert module and File behave exactly as measured above.

What remains for this issue once #306 is merged:

• Templates, Insert module, File: focus on opening from the keyboard.
• Data: the arrow keys, and focus on opening.
• Settings: decide what it is first. It declares role="menu" and holds no menu item.
• The toolbar overflow, Theme, Language, and the Distribution panel's export menu: measure, then decide.
• The mobile sheets.
• One more thing seen while measuring Help: activating an item that opens no dialog, such as the feedback link, closes the menu and leaves focus on the page body. Where focus should go then is part of the contract to write here.

[MerciHanrim]

The work for this issue is complete and in production. Closing it with what shipped, what was checked, and what is still not verified.

What shipped

• fix(menus): one keyboard contract for every menu, and the phone's sheets step back one level (v0.18.1) #322 (v0.18.1, d116779): every desktop menu button follows one keyboard contract (Templates, Insert module, File, Data, Help, the temporary-session chip, Settings → Theme and the Distribution panel's export). Enter, Space or a screen reader's activation opens at the first item; Arrow Down or Arrow Up on a closed button opens at the first or last item; arrows wrap, Home and End jump, Escape returns to the button, Tab and Shift+Tab close and move on. There is no typeahead.
• Theme's three choices are menuitemradio with aria-checked. Settings and ⋯ are disclosures with a labelled group, not menus. Language keeps its combobox.
• aria-controls is set only while the panel exists, on Settings, ⋯, File, the temporary-session chip and Theme, whose panels mount on open. Without it, Windows Narrator never read "expanded" on Settings or ⋯.
• On a phone, a sheet takes focus when it opens and is not modal: no aria-modal and no Tab trap, the run bar and the update bar stay usable, and only what the scrim covers (the canvas, the More button, the open-file card) leaves the keyboard and screen-reader order. Escape in a sheet opened from More goes back to More, on the row that opened it.
• A real aria-modal dialog is modal on every screen: everything outside its layer is inert, the run bar and the update bar included, except pure live regions. The update bar now sits below the tour and the dialogs, keeps its state while covered, and is usable again when the dialog closes.

Checked

• CI on the merge commit (run 37337715741): checks, the five end-to-end shards, the production bundle and the PWA all pass. On the pull request's head, the union of the five shards was exactly the planned 1,922 tests: 1,915 passed, 7 skipped by design, no retries.
• Production reports v0.18.1 · build d116779, and deployment 7b1d6cd1 is byte-identical to it (page, entry script, app chunk, stylesheet). The served bundle carries the 0.18.1 release note dated 2026-10-06 and still the 0.18.0 one, Theme's menuitemradio, the sheets' covered set, the tour's modal layer and the update bar's new z-index. Production was read with plain requests only.
• Manual check with Windows Narrator on the pull request's previews, by Hanrim, in both desktop Chrome (Chromium) and desktop Edge (Chromium): the Templates menu, About, Settings, Theme, the Storage and privacy dialog and the Language combobox. The missing "expanded" on Settings and ⋯ was found there in both browsers. On the final preview, Settings and ⋯ at 760 px read "expanded" and "collapsed" in both browsers.
• The automated suites run in Chromium only. The phone cases are automated tests in a 390 px Chromium viewport, not a check on a real phone or with a mobile screen reader.

Not verified, or still open

• Not checked for this issue: Firefox (Gecko), Safari (WebKit), a real phone, and any screen reader other than Narrator. The phone sheets were not checked with a screen reader.
• The release-note lines are in 18 languages; the 16 other than English and Korean have not been reviewed by a native speaker.
• The register expression field's combobox has the same structure as the panels above (a list that mounts on open, named by aria-controls while closed). It was left out of this change on purpose and needs its own review.