NVDA-Screen-Reader prevents toggle of dropdown menu

[sklein94]

Bug report

Current Behavior

When i am using the nvda-screen-reader in firefox / windows 10 and i navigate via keyboard to the trigger-button of a Dropdown, i cannot open it with the enter-key.

Expected behavior

Pressing the enter-key should toggle the dropdown-menu - even with nvda enabled.

Reproducible example

You can just visit your example-page: https://www.radix-ui.com/primitives/docs/components/dropdown-menu
Then you have to activate the nvda-screenreader in windows + firefox and make sure you are in browse-mode.

Somehow this is not reproducable with chrome as it seems to handle it different.

Suggested solution

Maybe you can just use the onClick-event instead of onkeydown/onPointerDown? At least this seems to work for the dialog-trigger-button.
Or do you have any workaround for me?

Additional context

This is a known behaviour of the nvda screen reader and as far es i understand they wont change this behaviour.
You can look here for more information: nvaccess/nvda#7898.
This is maybe also related to this issue: #1815.

This behaviour does not affect the trigger button for the dialog and as i studied your code, i found out that this is because you are using the onclick-event on the dialog-trigger-button:

primitives/packages/react/dialog/src/Dialog.tsx

Line 112 in c31c972

onClick={composeEventHandlers(props.onClick, context.onOpenToggle)}

But on the dropdown-trigger you use the onkeydown/onPointerDown-events

primitives/packages/react/dropdown-menu/src/DropdownMenu.tsx

Line 117 in c31c972

onPointerDown={composeEventHandlers(props.onPointerDown, (event) => {

The nvda-screenreader in browse-mode seems somehow to catch the enter-key-event and transform it in a click event - which is not captured by onPointerDown/onkeydown => Nothing happens

Your environment

• windows 10
• firefox
• nvda-screenreader

[jwueller]

From what I understand this is inherent in how the Firefox accessibility API works. Activating a button through that API always appears as a click event, not as a key event, regardless of how it was triggered.

It's odd, but since a button semantically doesn't have multiple activation states, Radix primitives should probably always listen for all possible events that activate it to be on the safe side. I don't think there is a case where you want the button to behave differently depending on how it was activated, since that seems semantically inconsistent.