MenuTrigger does not set isNonModal on PopoverContext, causing Popover to add role="dialog" around Menu

[Ovgodd]

Provide a general summary of the issue here

When using the MenuTrigger > Popover > Menu pattern, the Popover overlay element receives role="dialog", which is incorrect for a menu popup. This happens because MenuTrigger does not pass isNonModal: true through PopoverContext, so Popover defaults to treating itself as a dialog.

This causes screen readers to announce "dialog" when opening a menu, which is confusing for users and does not match the expected semantics of the WAI-ARIA APG Menu Button pattern.

🤔 Expected Behavior?

When a Popover is used inside a MenuTrigger, the overlay element should not have role="dialog". The popup should only contain role="menu" semantics, as specified by the WAI-ARIA APG Menu and Menubar pattern.

A screen reader should announce something like:

"Actions, menu button, collapsed" > (click) > "Open, 1 of 5"

No "dialog" should be announced.

😯 Current Behavior

The Popover overlay element gets role="dialog" even when used insideMenuTrigger`.

A screen reader currently announces:

"Actions, button" > (click) > "dialog, dialog, Open, 1 of 5"

💁 Possible Solution

Maybe add isNonModal: true to the PopoverContext value provided by MenuTrigger.

🔦 Context

We are building an accessible UI kit for that must comply with RGAA (the French transposition of WCAG). An our dropdown menus for announcing "dialog" via screen readers.

We use the recommended MenuTrigger > Popover > Menu pattern from react-aria-components. Since there is no clean way to prevent role="dialog" without using isNonModal (which has a warning discouraging its use), we aim to work around this with a MutationObserver that removes the attribute from the DOM as soon as Popover sets it.

🖥️ Steps to Reproduce

Open a menu with the screen reader enable and sees "dialog" displayling and check the popover in the DOM

Version

1.16.0

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

windows 11

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[devongovett]

While it's true that this is not exactly the same as the APG example, I don't think that means it's invalid. The reason for doing this is that menus often have additional elements within their popovers, such as search fields for filtering, interactive headers, etc. In those cases, the popover is a dialog containing a menu plus additional content (it cannot be within the role="menu" element, which only allows menu items as children). Other popovers that don't contain menus at all are also considered to be dialogs. So the question becomes: why should the specific case of menu-only popovers be considered different from all other kinds of popovers? When the menu opens, it announces both the dialog and the menu, so I think it's clear that you're on a menu inside a dialog. So while we could add additional logic to special case a popover that only contains a menu, I'm not sure it's worth the extra complexity.