DropdownMenu V2: Focus goes out when pressing Tab key

[t-hamano]

Description

The DropdownMenu V2 component allows you to use the arrow keys to move between menus in the same hierarchy without losing focus. However, if you press Tab or Shift+Tab, the focus will be lost from those menus.

In Dropdown V1, the Tab key does not remove focus, so the behavior in V2 feels like a bug to me.

Step-by-step reproduction instructions

You can test this behavior on Storybook.

DropdownMenu V2

https://wordpress.github.io/gutenberg/?path=/story/components-experimental-dropdownmenu-v2--with-submenu

v2.mp4

DropdownMenu V1

https://wordpress.github.io/gutenberg/?path=/story/components-dropdownmenu--default

v1.mp4

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[mirka]

I believe this behavior is intentional, and in line with the WAI-ARIA guidance on the Menu pattern. We should consider this a fix of the non-standard Tab behavior in Dropdown Menu v1.

[t-hamano]

Thank you for giving me that information. After reading that guidance, I think the current behavior in v2 components also makes sense.

If the v1 component needs to be fixed, should we leave this issue open?

[ciampo]

Agree with the sentiment around V2 behaviour feeling correct (cc'ing @diegohaz to confirm that the behaviour is indeed intentional)

If the v1 component needs to be fixed, should we leave this issue open?

We could technically leave this open, and close it when we merge the V2 implementation into the V1 (that's the goal for now).

Or we could close this as a wontfix. I'm fine with either options.

[diegohaz]

cc'ing @diegohaz to confirm that the behaviour is indeed intentional

Correct me if I'm wrong, but I think the DropdownMenu V2 in WordPress uses the modal prop, right? In this scenario, the Tab key press is managed by the browser or system as usual. It typically shifts focus to the next element outside the current window, including iframes. This behavior aligns with native modals (see Creating a modal dialog).

The reasoning behind this is that mouse users can already interact with elements outside the current window, whether it's the browser chrome or elements outside an iframe. So, this provides the same level of access to keyboard users.

[ciampo]

Correct me if I'm wrong, but I think the DropdownMenu V2 in WordPress uses the modal prop, right?

It is modal by default, but the prop is exposed, and so it can be set to false if needed. But I believe it was set to true in the example above.

In this scenario, the Tab key press is managed by the browser or system as usual. It typically shifts focus to the next element outside the current window, including iframes. This behavior aligns with native modals (see Creating a modal dialog).

The reasoning behind this is that mouse users can already interact with elements outside the current window, whether it's the browser chrome or elements outside an iframe. So, this provides the same level of access to keyboard users.

Makes sense, thank you for the clear explanation!

[ciampo]

I'm going to close this issue as we established:

• that the V1 behaviour likely won't be changed to preserve continuity with how the component behaved until today;
• that the V2 behaviour is the correct behaviour as per WAI-ARIA specs, and it will be an improvement over the v1 once released.