Material-ui: [Checkbox] a11y - Indeterminate checkbox state announces only as ticked or unticked rather than mixed

[ahayes91]

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

Current Behavior 😯

When I use indeterminate=true on MUI Checkbox component I would expect a screenreader to announce its state as mixed rather than ticked or unticked as per aria guidelines.
https://www.w3.org/TR/wai-aria-practices-1.1/examples/checkbox/checkbox-2/checkbox-2.html

Expected Behavior 🤔

I would expect an indeterminate checkbox to be announced as mixed instead of ticked or unticked, as per the example on https://www.w3.org/TR/wai-aria-practices-1.1/examples/checkbox/checkbox-2/checkbox-2.html

Steps to Reproduce 🕹

Steps:

1. Turn on VoiceOver on MacOS.
2. Navigate to https://material-ui.com/components/checkboxes/#basic-checkboxes in Chrome.
3. Tab navigate to the indeterminate checkbox and use the space key to tick/untick the box.
4. Will always be announced as ticked or unticked.

Context 🔦

Your Environment 🌎

| Tech | Version |
| ----------- | ------- |
| Mac OS | Catalina 10.15.4 |
| Chrome | Version 80.0.3987.163 (Official Build) (64-bit) |

[eps1lon]

Indeterminate checkboxes are pretty hard to get right. There are various inconsistencies between browsers and how react handles checked state (e.g. https://github.com/facebook/react/issues/18342).

It wouldn't surprise me if similar inconsistencies come up in different screen reader + browser combinations. I've created a fixture to narrow down the issue: https://5kfn6.csb.app/. The goal is to determine if the problem is: Material-UI, React or screen readers.

https://www.w3.org/TR/2016/WD-wai-aria-practices-1.1-20160317/examples/checkbox/checkbox-2.html

Seems like they don't implement a mixed state visually. At least in chrome 81 I can only differentiate between checked and unchecked for "All condiments"

Edit: @ahayes91 https://www.w3.org/TR/wai-aria-practices-1.1/examples/checkbox/checkbox-2/checkbox-2.html is the most recent one and does fix this issue. Should we reference that instead?

[ahayes91]

Edit: @ahayes91 https://www.w3.org/TR/wai-aria-practices-1.1/examples/checkbox/checkbox-2/checkbox-2.html is the most recent one and does fix this issue. Should we reference that instead?

Good find, I've updated the ticket to reflect that lad instead 👍

I'm doing some quick testing on https://5kfn6.csb.app and you're right about the screenreader/browser combos alright - not too many passes here as indicated by ✅:

Scenario being tested | VoiceOver MacOS on Safari 13.1 | VoiceOver MacOS on Chrome 81 | ChromeVox extension MacOS on Chrome 81 | NVDA Windows 7 on Firefox | VoiceOver iOS 13 on Safari
--- | --- | --- | --- | --- | ---
HTML unchecked indeterminate | unticked | mixed ✅ | not ticked | half-checked ✅ | unticked
HTML checked indeterminate | ticked | mixed ✅ | ticked | half-checked ✅ | ticked
React unchecked indeterminate | unticked | mixed ✅ | not ticked | half-checked ✅ | unticked
React checked indeterminate | ticked | mixed ✅ | ticked | half-checked ✅ | ticked
MUI unchecked indeterminate | unticked | unticked | not ticked | not checked | unticked
MUI checked indeterminate | ticked | ticked | ticked | checked | ticked

Kind of interesting to see too that a checked indeterminate checkbox on iOS will be rendered as a fully checked checkbox for HTML and React:

[eps1lon]

React unchecked

I guess you're only comparing the cases where indeterminate=true?

For our purpose it would be better if the HTML, React and Material-UI columns would be moved to the rows. This makes it easier to scan (for us) where the issue is.

[ahayes91]

React unchecked

I guess you're only comparing the cases where indeterminate=true?

For our purpose it would be better if the HTML, React and Material-UI columns would be moved to the rows. This makes it easier to scan (for us) where the issue is.

Sorry I've clarified that a bit now. Would like to test JAWS and Talkback too but I'm hindered by my devices here on COVID-19 lockdown 😂

[eps1lon]

Would like to test JAWS and Talkback too but I'm hindered by my devices here on COVID-19 lockdown joy

I can do that. But looking at the "VoiceOver MacOS + Chrome 81" results it seems like we definitely need to work on it.

[oliviertassinari]

I had forgotten about this past iteration on the problem: #12772.

[oliviertassinari]

Does https://baseweb.design/blog/screen-reader-improvements#components-should-announce-their-state handle it correctly?

[eps1lon]

Does baseweb.design/blog/screen-reader-improvements#components-should-announce-their-state handle it correctly?

They don't use native checkboxes so it doesn't really relate to this issue.

Features of native checkboxes have a bunch of inconsistencies in various browsers depending on the timing or how their props are changed. If you don't leverage native forms and need the mixed state then custom ARIA implementations may be a bit more robust. Though pure ARIA implementations are usually more prone to screen reader issues.

I'd go with my usual stance: Just because they say they're accessible doesn't mean they are. You need tests for that.