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: https://github.com/nvaccess/nvda/issues/7898. This is maybe also related to this issue: https://github.com/radix-ui/primitives/issues/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: https://github.com/radix-ui/primitives/blob/c31c97274ff357aea99afe6c01c1c8c58b6356e0/packages/react/dialog/src/Dialog.tsx#L112

But on the dropdown-trigger you use the onkeydown/onPointerDown-events https://github.com/radix-ui/primitives/blob/c31c97274ff357aea99afe6c01c1c8c58b6356e0/packages/react/dropdown-menu/src/DropdownMenu.tsx#L117

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.