This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
HTML5 should provide true support for tri-state checkboxes and menu items (those with states of checked, unchecked, and indeterminate/mixed/undefined), as well as other controls with indeterminate/mixed/undefined state. This will let user agents provide standardized user interface for such controls, and let assistive technology provide alternative input and output for them. Not providing this would mean authors and developers would still have to implement custom controls and behaviors for an extremely common feature, and these would not be compatible with assistive technology. We recognize that for checkbox controls there are backward compatibility issues with the Boolean checked attribute; this could be addressed by any of a number of means, such as providing a new attribute to indicate a indeterminate/mixed/undefined state or changing the semantics and behaviors of the existing indeterminate attribute so that it was no longer defined as being purely cosmetic. Use case: Aidan uses speech recognition for input. When he views an interactive web page or web-based application that uses standard HTML5 controls, his speech recognition program can let him control them using standardized commands, such as checking or unchecking recognized checkboxes by saying "Check italic" or "Uncheck bold". However, when it encounters custom controls or controls with nonstandard behaviors, he has to resort to saying actual keystrokes, such as "Press tab. Press tab. Press tab. Press space." He uses a web-based text editor that provides a tri-state check box that is checked with the entire selection is italicized, unchecked when the entire selection is not italicized, and in a third, "mixed" state when only part of the selection is italicized. In one scenario, he accidentally checks the Italics check box then realizes he wants to change it back to the "mixed" state. Let's say it's implemented as an HTML5 input element with type=checkbox, but with scripting to handle the tristate behavior (perhaps as described in Shams' Blog: Tri-State Checkbox using Javascript - http://shamsmi.blogspot.com/2008/12/tri-state-checkbox-using-javascript.html); in this case the keyboard UI is not standardized, so the speech recognition utility cannot provide a corresponding voice command. In a second scenario, it's implemented as an entirely custom control. Use case: Nadia uses a screen reader with the same web-based text editor that provides a tri-state checkbox for indicating and adjusting italics. Regardless of whether the author used an HTML5 input element with type=checkbox or if they used an entirely custom control, the screen reader has no way of determining which state it's really in, and so can't convey this to Nadia using speech. Use case: Ryan, a keyboard user, is using the same web-based text editor that provides a tri-state checkbox for indicating and adjusting italics. Unfortunately, because each web site or web-based app has to implement its tri-state checkbox itself, they often implement entirely different keyboard UI, and so when Ryan comes to one he cannot easily figure out how to use it with the keyboard.
mass-move component to LC1
Mass move to "HTML WG"
(In reply to comment #0) > HTML5 should provide true support for tri-state checkboxes and menu items > (those with states of checked, unchecked, and > indeterminate/mixed/undefined), as well as other controls with > indeterminate/mixed/undefined state. This will let user agents provide > standardized user interface for such controls, and let assistive technology > provide alternative input and output for them. Not providing this would mean > authors and developers would still have to implement custom controls and > behaviors for an extremely common feature, and these would not be compatible > with assistive technology. The major problem here seems to be that assistive technology isn't [yet] equipped to deal with HTML5's indeterminate checkbox behavior. The reason why this is likely hard to do, is because an AT can't know just based on the markup, whether the behavior of the indeterminate checkbox should be truly tri-state (e.g., unset -> indeterminate -> set (repeat)) or simple pseudo tri-state (e.g., indeterminate -> set -> unset -> set -> unset (etc.)). The web developer can model either behavior with JavaScript with the current HTML5 control. > We recognize that for checkbox controls there are backward compatibility > issues with the Boolean checked attribute; this could be addressed by any of > a number of means, such as providing a new attribute to indicate a > indeterminate/mixed/undefined state or changing the semantics and behaviors > of the existing indeterminate attribute so that it was no longer defined as > being purely cosmetic. The current pseudo-tri-state checkbox is itself a very useful concept, not one that we'd like to change. Having said that, the true tri-state control is also very useful--though I disagree with the use cases cited in this bug (the behavior for setting the checkbox back to indeterminate to mean "undo" is probably not right). As noted, a true-tri-state control could be added in several ways: 1) a new element (e.g., <threebox></threebox>), 2) extending the <input> types (e.g., <input type="tristatebox">), or 3) signaling the tri-state behavior to existing checkboxes (e.g., <input type="checkbox" tristate>). I don't really like the first option because it introduces a new element that is very, very similar to the input type=checkbox in so many respects. It also has to define a content model (which would probably be similar to <input>'s whereby legacy user agents would handle the inner content as fallback behavior (into which a real <input type="checkbox"> would need to be placed). This seems like a lot of unnecessary duplication to me--though others might argue. Techniques 2 and 3 are virtually identical in the set of problems they'd need to overcome. Basically, the OM for the <input type=checkbox> has 4 states today for a pseudo-indeterminate checkbox: State A: indeterminate + checked State B: indeterminate + not checked State C: not indeterminate + checked State D: not indeterminate + not checked The user experience for a true tri-state checkbox would need to cycle among three of these four states. Consider two example cycles: * D->A->C (repeat) - where the indeterminate state is more truthy than falsy (for reads on the .checked IDL attribute) * D->B->C (repeat) - where the indeterminate state is more falsy Either cycle behavior may be desireable depending on the fallback scenario for user agents that wouldn't support the new tri-state control. A solution to the above cycle choice problem may be that the use of the "checked" content attribute is taken as a hint to the UA to use either state A (if checked is present) or state B (if checked is not present). Also, other than the tri-state mode trigger, you'd want yet another content attribute "indeterminate" (and corresponding "defaultIndeterminate" IDL attribute) to hint the initial state of the UI to be indeterminate. I think this is a great opportunity for an extension spec for integrating true Tri-state checkboxes in HTML5.1. There are still a lot of potential issues to work out, however. Greg, are you interested in developing an extension spec for this feature?
(In reply to comment #4) > The major problem here seems to be that assistive technology isn't [yet] > equipped to deal with HTML5's indeterminate checkbox behavior. The reason > why this is likely hard to do, is because an AT can't know just based on the > markup, whether the behavior of the indeterminate checkbox should be truly > tri-state (e.g., unset -> indeterminate -> set (repeat)) or simple pseudo > tri-state (e.g., indeterminate -> set -> unset -> set -> unset (etc.)). The > web developer can model either behavior with JavaScript with the current > HTML5 control. Of course this is hard to detect from markup, since there's no "indeterminate" content attribute! Just wanted to make that correction...
Hi Travis, not quite understanding the intracies of the checkbox states, but i thought the aria-checked attribute provided AT support for tristate checkboxes http://www.w3.org/TR/wai-aria/states_and_properties#aria-checked An old (2008) working example with reported states http://www.paciellogroup.com/blog/misc/ARIA/tristatecheck.html
I forgot to add this http://www.w3.org/WAI/PF/aria-implementation/#mapping_state-property_table which details how the ARIA checked states are mapped to the various platform accessibility APIs
(In reply to Greg Lowney from comment #0) > HTML5 should provide true support for tri-state checkboxes and menu items > (those with states of checked, unchecked, and > indeterminate/mixed/undefined), as well as other controls with > indeterminate/mixed/undefined state. This will let user agents provide > standardized user interface for such controls, and let assistive technology > provide alternative input and output for them. Not providing this would mean > authors and developers would still have to implement custom controls and > behaviors for an extremely common feature, and these would not be compatible > with assistive technology. > > We recognize that for checkbox controls there are backward compatibility > issues with the Boolean checked attribute; this could be addressed by any of > a number of means, such as providing a new attribute to indicate a > indeterminate/mixed/undefined state or changing the semantics and behaviors > of the existing indeterminate attribute so that it was no longer defined as > being purely cosmetic. > > Use case: Aidan uses speech recognition for input. When he views an > interactive web page or web-based application that uses standard HTML5 > controls, his speech recognition program can let him control them using > standardized commands, such as checking or unchecking recognized checkboxes > by saying "Check italic" or "Uncheck bold". However, when it encounters > custom controls or controls with nonstandard behaviors, he has to resort to > saying actual keystrokes, such as "Press tab. Press tab. Press tab. Press > space." He uses a web-based text editor that provides a tri-state check box > that is checked with the entire selection is italicized, unchecked when the > entire selection is not italicized, and in a third, "mixed" state when only > part of the selection is italicized. In one scenario, he accidentally checks > the Italics check box then realizes he wants to change it back to the > "mixed" state. Let's say it's implemented as an HTML5 input element with > type=checkbox, but with scripting to handle the tristate behavior (perhaps > as described in Shams' Blog: Tri-State Checkbox using Javascript - > http://shamsmi.blogspot.com/2008/12/tri-state-checkbox-using-javascript. > html); in this case the keyboard UI is not standardized, so the speech > recognition utility cannot provide a corresponding voice command. In a > second scenario, it's implemented as an entirely custom control. > > Use case: Nadia uses a screen reader with the same web-based text editor > that provides a tri-state checkbox for indicating and adjusting italics. > Regardless of whether the author used an HTML5 input element with > type=checkbox or if they used an entirely custom control, the screen reader > has no way of determining which state it's really in, and so can't convey > this to Nadia using speech. > > Use case: Ryan, a keyboard user, is using the same web-based text editor > that provides a tri-state checkbox for indicating and adjusting italics. > Unfortunately, because each web site or web-based app has to implement its > tri-state checkbox itself, they often implement entirely different keyboard > UI, and so when Ryan comes to one he cannot easily figure out how to use it > with the keyboard. I have tested the indeterminate IDL attribute in Firefox/IE and Chrome. I found that when the attribute is set to true all the above browsers provide a visual indication of the indeterminate state. indeterminate=true is also coveyed as the MSAA 'mixed' state in Firefox and Chrome, but not Internet Explorer. I have filed a bug on IE https://connect.microsoft.com/IE/feedback/details/907974/html-checkbox-indeterminate-idl-state-not-exposed-in-accessibility-layer test case: http://stevefaulkner.github.io/html-mapping-tests/browser-tests/checkbox-states.html
To confirm/extend Steve's findings... The checked/unchecked state is accessibility supported in Chrome, Firefox, IE and Safari. The indeterminate state is exposed in Chrome and Firefox, but not IE or Safari. Jaws and NVDA announce all three states correctly in Chrome and Firefox on Windows. Window-Eyes announces all three states correctly in Firefox and IE on Windows. VoiceOver announces the checked/unchecked states correctly in Safari on OS X and iOS, but not the indeterminate state. TalkBack announces the checked/unchecked states correctly in Chrome on Android, but not the indeterminate state. Test cases and notes available here: http://ljwatson.github.io/test-cases/checked-state/checked.html Information about state seems to be natively available for the taking. I'm not sure there is anything we should be doing except filing bugs with browser and assistive tech vendors?
Closing, per agreement reached on the HTML A11y TF on 29th Jan 2015: http://www.w3.org/2015/01/29-html-a11y-minutes.html#item04