Menu: reconsider the modal behavior

[afercia]

Description

Splitting this out from #67078, which reports a few more issues with the Menu component.

The Menu component implementation is based on the Ariakit library and, so far, it uses a modal behavior. That is, when a meny is open, interaction with the rest of the page is prevented. There have already been discussions on whether to use the modal behavior for the Menu but they occurred in more general issues while I would like to have a discussion specifically on this point.

The more I test this behavior, the more I'm confused by it.

For example, in the Site editor > Templates page, I was confused and staring at the screen because I couldn't understand why spme buttons didn't do anything when clicking them. I had to click twice to make them do something.

Actually, like for a modal dialog, the Menu modal behavior does add an overlay 'backdrop' to prevent intereaction with the rest of the page.

But...

the overlay is transparent. Users don't have any visual indication that the interaction with the rest of the page is intentionally prevented. As such, clicking on other controls in the UI and seeing that nothing happens is very confusing. This is very different from, for example, the odal behavior of a dialog where the overlay backdrop is visible.

Video to better illustrate.
At some point, I'm adding some background color to the overlay to better illustrate when it prevents interacting with the rest of the page.

Screen.Recording.2025-01-22.at.10.20.07.mov

Overall, I think the user experience is very confusing.
I'd like to reconsider whether the modal behavior adds any benefit for users, including keyboard users and assistive technology users.

Step-by-step reproduction instructions

• Go to Site editor > Templates.
• Click the ellipsis button of a template card.
• A dropdown menu opens. Keep it open.
• Click the ellipsis button of another template card.
• Observe that nothing happens.
• Click again.
• Observe this time something happens (the othe rmenu opens).
• Click the preview of another template card.
• Observe that nothing happens.
• Click again.
• Observe this time something happens.

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

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[Rishit30G]

Thanks for sharing the issue @afercia,

I'm sharing a screencast which introduce a new modal backdrop, to me it looks like a proper modal which gives the user an indication that the other options on the page are not selectable
Would appreciate your thoughts on this one 🙇🏻

Thanks

Screen.Recording.2025-01-23.at.8.57.23.AM.mov

[afercia]

Thanks @Rishit30G for your feedback and example. Personally, I think the modal behavior should be either entirely removed or kept but in this case it should provide a visual indication e.g. the overlay should be visible like in your example. However, I'm not sure why a menu should prevent interaction with the rest of the page in the first place.

I guess the current implementation is inspired by the interaction with menus in some operating systems. For example, on macOS, when a menu of the operating system is open then interacting with the currently active window is prevented. That makes sense because the UI of the menu in the operating system and the active window are clearly separated. Video:

Screen.Recording.2025-01-23.at.08.38.14.mov

Things become less consistent when the active window itself has an open menu and trying to interact with a control in the rest of the active window. Quickly testing with browsers:

• Chrome: open a Chrome menu and try to click a link in the rest of the page: interaction is prevented (the menu is modal).
• Firefox: open a Firefox menu and try to click a link in the rest of the page: the link is clickable (the menu isn't modal).
• Safari: same as Firefox.

That's to say that if this implementation has been inspired by some existing behaviors in operating systems, that source of inspiration is inconsistent in the first place and I'm not even sure other operating systems use the same pattern.

Regardless, I'd tend to think the users expectation would be the interaction with the rest of the page to not be prevented.

Worth also noting the ARIA menu bar and menu button examples don't use any modal behavior.

Before any coding, I'd think the reasons why the menu current implementation is modal should be investigated and see if the arguments for the modality are still valid.

[Rishit30G]

Points well stated, thanks for clear explanation and examples on the modal behaviour! 🙇🏻

Edit: I tried removing the overlay, just to check the functionality but seems like it's not removing, or there is some other way to do it 🤔

Screen.Recording.2025-01-24.at.12.26.00.PM.mov

[afercia]

@Rishit30G have you tried to set the Menu modal prop to false?

The Menu implementation is based on the external library Ariakit, so the modal behavior may be an Ariakit internal implementation.

[Rishit30G]

Thanks @afercia! 🙇🏻
The implementation shared works, now we have the access to the other elements even when the menu is open
Now based on the final discussion we should come to a conclusion that either we don't need the modal or we need a modal with a light dark opaque backdrop

Screen.Recording.2025-01-27.at.11.02.12.AM.mov

[afercia]

Cc @joedolson can this be discussed at the next accessibility bug-scrub?