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

[ahayes91]

• 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 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. facebook/react#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.

[DiegoAndai]

@oliviertassinari should we add the ready-to-take label for anyone interested in picking this up to update the benchmark and decide what to do regarding this issue?

[Mike-Gilge]

Do you have any updates as to when this issue will be addressed or what we can do in the mean time?

[DiegoAndai]

Hey @Mike-Vega. As discussed in this issue, there's no current standard for handling the indeterminate checkbox state. In the meantime, you should be able to pick a way of handling that works for you and provide the respective aria attributes.

I'll add this issue to the "Material UI with Base UI" milestone, to be resolved after the Material UI Checkbox is built upon the Base UI Checkbox.

@atomiks, this might be something to remember while working on the Checkbox for Base UI.

[Mike-Gilge]

I should have clarified I am having this issue with the select all on the data grid and was wondering if there might be a fix?

[cherniavskii]

@Mike-Vega Could you open an issue in https://github.com/mui/mui-x so we can investigate?
Thanks!