[Select] Fails when using screen reader or keyboard navigation

[attilavago]

While generally the accessibility functionality of the MUI Multi-select is decent, it would still fail any audit due to inconsistent screen reader behaviour and keyboard navigation. See further details below.

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behaviour 😯

Screen Readers (SR)

Win10/Chrome/ChromeVox

When I navigate to the select that has preselected entries, these are not announced to me unless I open the menu and navigate to each of the entries. It is possible to open the menu and select/deselect ok with enter key, space doesn’t work. No instructions for the user either, and the select is announced as a ‘button’ and I’m not informed when menu is expanded or collapsed. Not an ideal experience. Would fail an audit.

Win10/Chrome/Jaws

Slightly better experience (announces as expanded, gives instructions to navigate list), but JAWS won’t announce which of the entries have been ticked/selected. You have to close the menu and listen to the chips to determine that. Would fail an audit.

Win10/Firefox/NVDA

Can navigate menu using Insert+Space, then arrow keys, however selected entries are not announced, as per above. Would fail an audit.

Mac10.14/Chrome/VoiceOver

Shares the same issues as above. Would fail an audit.

Overall

• SR doesn’t announce which of the entries have been ticked/selected.
• SR doesn’t allow user to use spacebar to select/check entries.
• SR doesn’t always announce when the listbox has been expanded or collapsed.
• SR doesn’t reliably read the selected entries when the menu is collapsed (e.g. chips)

Keyboard Navigation

It works with TAB to select, up/down arrow or Enter to open and Enter key to select entry, but doesn’t work with space to select, this would be expected behaviour.

Expected Behaviour 🤔

• SR must announce which of the entries have been ticked/selected.
• SR must always announce when the listbox has been expanded or collapsed.
• In keyboard navigation mode and while using SR we must allow user to use spacebar to select/check entries. See HTML5 example: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_select

Steps to Reproduce 🕹

Try the following example with the above mentioned screen readers and using the keyboard only: https://cwvg4.csb.app/

Context 🔦

The goal is to meet the WCAG 2.0/2.1 AA standard as legal audit requirement for a learning platform used by millions of students, teachers and administrators.

Your Environment 🌎

Tech	Version
Material-UI	v4.9.10
Browser	Firefox (latest), Chrome (latest)
Screen Reader	Jaws, VoiceOver, NVDA, ChromeVox
OS	MacOS 10.14, 10.15, Windows 10

[AnnemarieMcc]

Hi there. I'd like to add to what @attilavago reported please - we're planning to use this multi-select component in an upcoming (WCAG 2.1 compliant) release and would appreciate any info you can provide around a release roadmap for these fixes when you've had a chance to review. Many thanks.

[eps1lon]

Thank you so much for this report!

This is definitely something that we want to look into when working on v5. I can't promise any backports of these fixes to v4 though.

[oliviertassinari]

I think that we should avoid backports as much as possible, the opportunity cost is high.

[AnnemarieMcc]

Thanks for the feedback. What's the estimated release date for V5 please? Cheers

[oliviertassinari]

@AnnemarieMcc 2021 but they will be plenty of alpha and beta versions before. If there is an easy fix for this, we might as well do it now :)

[AnnemarieMcc]

@AnnemarieMcc 2021 but they will be plenty of alpha and beta version before. If there is an easy fix for this, we might as well do it now :)

Yes - that would be fantastic. We're legally required to be WCAG compliant so using this component in it's current state wouldn't be an option for us. Please keep us posted with your progress - it would help us plan our release and the need to use a workaround if required. Happy to carry out some regression testing on alpha/beta versions. Appreciate your help 🙂

[attilavago]

@AnnemarieMcc 2021 but they will be plenty of alpha and beta version before. If there is an easy fix for this, we might as well do it now :)

If I may chime in here, it would be great to have this solved as early in v.4 as possible. I've also checked in v.3, so this is technically not a new bug. Given the fact that release of v.5 seems to now have slipped to 2021 from Q3 2020, I'd advocate for a v.4 fix rather than a v.5 especially these days when so many people are finding themselves having to use the web to get their day to day stuff done, which only means even more disabled folks are interacting with these components.

[oliviertassinari]

seems to now have slipped to 2021 from Q3 2020

@attilavago I would name that shift: not over-promising :). If you have $ on the line (legal risk), note that you have a couple of options:

1. Material-UI has a custom-work offering: https://material-ui.com/getting-started/support/#custom-work
2. Migrate to use the Autocomplete component instead.
3. You could explore the issue and come up with a pull request, even if we don't accept it in the timeline that matches your requirements, you could still use the patch internally.

[attilavago]

seems to now have slipped to 2021 from Q3 2020

@attilavago I would name that shift: not over-promising :). If you have $ on the line (legal risk), note that you have a couple of options:

1. Material-UI has a custom-work offering: https://material-ui.com/getting-started/support/#custom-work
2. Migrate to use the Autocomplete component instead.
3. You could explore the issue and come up with a pull request, even if we don't accept it in the timeline that matches your requirements, you could still use the patch internally.

These are actually some great suggestions. That 3rd one particularly. Thanks @oliviertassinari!

[scottschup]

Any updated timeline estimates for this fix? Coming up on a year since this thread saw any activity :/

@attilavago, did you/your team come up with any temp patches you'd be willing to share?

[oliviertassinari]

@scottschup if this is important for you, your best chance would be to work on the problem.

[scottschup]

Right on, just wanted to check before I did.

[Dan503]

My solution:
Just use a regular native <select> element and then style the outside to look how you want. The MUI select gives you a fancy looking options menu but it doesn't provide any functional benefit ​to the user that a native <select> element doesn't provide.

The outside of a native select element is very easy to style with CSS.

Until this issue is fixed, if you go with the MUI Select you are blocking disabled users from using that form control just so the options menu looks a little bit prettier.

[Brian-Gaffney]

This issue is still a problem for us.

We're aiming for full accessibility and having to work around this limitation is hurting us a bit.
Native selects stand out in our app where everything else is using MUI.

Using the autocomplete is better for accessibility but feels like overkill for situations where there are only 4 or 5 items.

Just my 2c trying to keep this issue alive and bump the priority of making it accessible.