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

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

           Summary: Fully support tri-state and indeterminate controls
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Keywords: a11y, a11ytf
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: gcl-0039@access-research.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org, public-html-a11y@w3.org


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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 2 August 2011 00:06:17 UTC