[Bug 13508] Fully support tri-state and indeterminate controls

https://www.w3.org/Bugs/Public/show_bug.cgi?id=13508

--- Comment #8 from steve faulkner <faulkner.steve@gmail.com> ---
(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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 28 June 2014 12:05:19 UTC