MenuItems not reading in Windows with NVDA/JAWS after upgrade from v1 to v5

[dakahn]

• downshift version: v5.0.3
• node version: 12.16.1
• npm (or yarn) version: 1.21.1

Relevant code or config
https://github.com/dakahn/carbon/blob/upgrade-downshift-dependency/packages/react/src/components/Dropdown/Dropdown.js
Our Dropdown has a ListBox component as a dependency
https://github.com/dakahn/carbon/tree/upgrade-downshift-dependency/packages/react/src/components/ListBox

What you did:
Upgraded Downshift from v1 straight to v5

What happened:
After the upgrade this Dropdown component's menuitems are not longer being read by NVDA or JAWS in Windows 10

Reproduction repository:
https://deploy-preview-5373--carbon-components-react.netlify.com/iframe.html?id=dropdown--default

Problem description:
When using NVDA or JAWS 2020 in Windows 10 the menuitems are not being read. It seems like focus is never moving from the input field on the combobox. The a11y announcer doesn't seem to changing sub tree to menu items like expected. This is the markdown output with a menu option receiving focus

So like you'd expect as you use up and down arrows through the menuitems it just repeats "5 results are available...".

Honestly any help with this would be great. The problem seems to be isolated to Windows environments which is interesting. Testing with VoiceOver on macOS the menuitems read as expected.

[silviuaavram]

First things first I don't see any input field. It seems that you actually have a select rather than a combobox. Maybe give useSelect a try if you have a function component.

We are not narrating using that aria-status-message anymore as this is supposed to be done by the screen reader automatically. In your case it's not happening because there is no aria-activedescendant on that button you keep focus on.

2 solutions: 1 - use the hook I mentioned above (recommended but I don't know what's your implementation, it may take longer than the second suggestion). 2 - get aria-activedescendant from getInputProps and use that on the button.

Solution 2 is simpler but it will not make your dropdown accessible. Screen readers on Windows will not enter in Forms Mode when interacting with the dropdown. That is why useSelect should be used. It's designed for this specific case. When the dropdown opens, useSelect will put the focus on the menu, so the screen reader will go into Forms/Application mode, because the menu has role="listbox".

Strongly suggest you to use the hook :). Good luck!

[dakahn]

After some testing implementing solution 2 today I can confirm you're right. No menu-items are spoken with either NVDA/JAWS 2020 in Windows 10. Going to dig into solution 1 then 👍

[silviuaavram]

Let me know how it goes, it will be interesting to find out how you migrated from v1 to a hook👍

[dakahn]

We finished our upgrade from v1 to v5 which included the above mentioned React Hooks refactors of various select components 🏄
carbon-design-system/carbon#5373