`ContextualMenu` options do not receive keyboard focus when opened with mouse

[jademathre-canonical]

Open the toggle with a mouse.
Notice that the options cannot be reached using the keyboard (arrow keys or tabbing).

[edlerd]

I guess this is about the dropdown links 1 and link 2? I can access both after opening the toggle with the keyboard. Actually, they automatically receive focus. Maybe a Storybook issue. Did you try on the detail page? Or it might be a browser/OS combination that behaves differently, @jademathre-canonical ? I am on the latest Chrome in Ubuntu.

[jmuzina]

Opening the contextual menu toggle story, I was able to reach the options with the keyboard - they are autofocused immediately when opened. This was implemented in #1298 . Are you able to repro that?

For context for others: we noticed in a 360 PR on the /notes page that, when using keyboard to delete a note, or edit a note while another note is already being edited, (both actions triggered by contextual menu options), the resulting confirmation modal did not receive automatic focus. This may actually be a specific faulty interaction of contextual menus opening confirmation modals with conflicting focus management, similar to #1305

[jademathre-canonical]

The toggle does work properly for me as well in the links provided--just not on the docs page. I do wonder if the storybook issue (which is similar to the 360 notes issue) is related to having multiple contextual menus on the same page?

[jmuzina]

The toggle does work for me on the docs page as well - I'm using latest Chromium on Ubuntu, what are you using?

[jademathre-canonical]

Latest Chrome on Ubuntu. If I click on the toggle, and press tab, this is what I see:

Screencast.from.2026-04-28.13-21-01.mp4

[jmuzina]

Ah, I can repro that. I was opening the context menu with the keyboard (tabbing to it then pressing ENTER), not clicking it as you are. I do think it is expected that the first item would not be focused when opening via mouse (it would be visually distracting), but you are right that the menu options are not reachable by keyboard after opening the menu with a mouse, as they should be (note: in this example the menu is navigable with arrow keys, not tab, as they really should be per wcag spec).

So, there's two issues with the context menu itself here:

1. The menu items are not keyboard-interactable when the menu was opened by mouse instead of keyboard
2. The menu items are navigated via Tab instead of arrows, so while fixing issue 1 above we may encounter issues with tab indices that we would not have if we were using arrow keys

Any solution to this should stay away from relying on tabindex for the fix, as it would increase our reliance on TAB instead of arrow-keys which is counter to WCAG spec.

Ideally, we should fully rework the keyboard interactions here so that the component listens for arrow key events whenever it is opened.
Practically, I'm not sure what the LOE would be to make the change to arrow-keys instead of tab, maybe it would be a breaking change - it needs investigation - potentially we could make a smaller change to focus the first item when tab is pressed while the menu is open and no menu items are yet focused, then later overhaul the keyboard interactions to comply with WCAG spec, what do we think?

[jademathre-canonical]

My inclination would be to overhaul it all at once, but I'm oft guilty of scope creep.

[edlerd]

potentially we could make a smaller change to focus the first item when tab is pressed while the menu is open and no menu items are yet focused, then later overhaul the keyboard interactions to comply with WCAG spec, what do we think?

Personally, I think fixing the tab behavior is the right fix.

I am not 100% convinced we should go with arrow keys. For two reasons:

• It is indeed a breaking change that would confuse existing users.
• It seems confusing if an app sometimes relies on tab and sometimes on arrow keys.

The second one is more important, as it defines the right long-term solution. I might be missing something, as I am not a heavy keyboard user in web UIs.

[jademathre-canonical]

I would content that the current behavior (using tab instead of arrow keys) is non-standard and would be confusing for users who generally keyboard navigate:
https://www.w3.org/WAI/ARIA/apg/patterns/menu-button/#:~:text=behave%20as%20links.-,Keyboard%20Interaction,-With%20focus%20on

A mix of arrow keys and tabs, with each serving a different purpose:
https://dequeuniversity.com/tips/aria-keyboard-patterns#:~:text=Tab%20to%20It%2C%20Use%20Arrow%20Keys%20Within%20It

[paul-geoghegan]

Scope creep fan here!

The standard and best for context menus is arrow navigation and I wouldn't even attempt to press tab while in a context menu as I would expect that to leave it.
Tab and arrows perform 2 different functions and that is the expected behavior.

The first item should definitely gain focus if you open it with a mouse and then press tab.
IMO the arrow key fix is more important as if you're using a mouse to open it you could probably use it to select an option while not being able to arrow through the options is definitely off putting.

I had difficulty using the menu myself in FF on latest but Storybooks is hit and miss on focusing in my experience.