477572 - Properly support indeterminate checkboxes with the right a11y notifications

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Jeff Walden [:Waldo]]

Basically, there's an "indeterminate" property on checkboxes, and when it's set the checkbox is in a special state that's neither checked nor unchecked.  The checkbox shouldn't appear to screen readers or such creatures as checked or unchecked, because it's really neither.

See the URL for a description of the DOM property and a test page that demonstrates it.

Comment 1

[Jeff Walden [:Waldo]]

Actually, the original URL described it but didn't like to the page that demonstrated it, choosing to put a screenshot in but no link.  :-)  Changing to the actual test page instead...

Comment 2

[Marco Zehe (:MarcoZ)]

The testcase shows that, for the indeterminate checkbox, we currently expose the "checked" state. We should expose nsIAccessibleStates::STATE_MIXED instead if that DOM property is true.

Comment 3

[Marco Zehe (:MarcoZ)]

Attachment: WIP for discussion

I confirmed that this does what it is supposed to. Need to write mochitest. Is this the right approach?

Comment 4

[alexander :surkov (:asurkov)]

Yes, sounds correct. Would be nice to see deepened bug where this property was implemented. You could use test_nsIAccessible_states.html (as well you might to rename it to test_states.html).

There is another point. We expose "check"/"uncheck" action name, which action name should be reserved for indeterminate state?

Comment 5

[Marco Zehe (:MarcoZ)]

Attachment: Patch with mochitest

Patch that includes a mochitest. Starts out with checked, then sets to unchecked, then sets to indeterminate.

Robert, is this the right way to call the two interfaces, or is there a more elegant way to do it?

Comment 6

[alexander :surkov (:asurkov)]

Do I understand correct indeterminate checkboxes don't work without JS?

Marco, what about actions and events? Do you prefer to save this for another bug?

Comment 7

[alexander :surkov (:asurkov)]

Comment on attachment 361277 [details] [diff] [review]
Patch with mochitest


>+  PRBool mixed = PR_FALSE;     // or mixed.
> 
>+  nsCOMPtr<nsIDOMNSHTMLInputElement>
>+           html5CheckboxElement(do_QueryInterface(mDOMNode));

technicaly NS is not html5.

>+  if (html5CheckboxElement) {
>+    html5CheckboxElement->GetIndeterminate(&mixed);
>+
>+    if (mixed)
>+      *aState |= nsIAccessibleStates::STATE_MIXED;

If I get right once we are mixed then we can't be checked. We don't need to call GetChecked().

>+        checkboxElem.checked = false;
>+        testStates(checkboxElem, 0, 0, STATE_CHECKED);
>+        checkboxElem.indeterminate = true;
>+        testStates(checkboxElem, STATE_MIXED, 0, STATE_CHECKED);

I would prefer to have markup (not js) based tests but it seems "indeterminate" is available from script only. There is no "indeterminate" attribute?


>+  <input type="checkbox" id="check1" name="check1" value="I agree" checked="true"/>

why do you tend to give @name attribute for every form control?

Comment 8

[Marco Zehe (:MarcoZ)]

(In reply to comment #6)
> Do I understand correct indeterminate checkboxes don't work without JS?

Alex, as far as I understand it from this blog post:
https://developer.mozilla.org/web-tech/2009/02/05/a-new-checkbox-type/, yes, this is assigned through JS.

> Marco, what about actions and events? Do you prefer to save this for another
> bug?

I didn't see any problem with events. When focused on a partially checked checkbox and pressing SPACE, like on the test page, the state goes to "not checked", which may be specific to this scenario.

And that brings me to actions: We never know if pressing SPACE on a partially checked checkbox will check or uncheck the whole thing. This is determined by the web app, so I am not sure what the actions should be here. I'd prefer to discuss this and move that part to another bug, but get the state exposed properly.

Comment 9

[Marco Zehe (:MarcoZ)]

(In reply to comment #7)
> (From update of attachment 361277 [details] [diff] [review])
> 
> >+  PRBool mixed = PR_FALSE;     // or mixed.
> > 
> >+  nsCOMPtr<nsIDOMNSHTMLInputElement>
> >+           html5CheckboxElement(do_QueryInterface(mDOMNode));
> 
> technicaly NS is not html5.

Well, this is the interface that implements the HTML 5 specific property, so I wanted to make clear that we're dealing with something HTML-5-specific here.

> 
> >+  if (html5CheckboxElement) {
> >+    html5CheckboxElement->GetIndeterminate(&mixed);
> >+
> >+    if (mixed)
> >+      *aState |= nsIAccessibleStates::STATE_MIXED;
> 
> If I get right once we are mixed then we can't be checked. We don't need to
> call GetChecked().

OK, will return at the end of this if block if we're setting the state.

> I would prefer to have markup (not js) based tests but it seems "indeterminate"
> is available from script only. There is no "indeterminate" attribute?

See my other comment: As far as I understood, this is a JS only thing right now.

> >+  <input type="checkbox" id="check1" name="check1" value="I agree" checked="true"/>
> 
> why do you tend to give @name attribute for every form control?

Dunno, something I learned to do once in my HTML course at university, and it stuck.

Comment 10

[Michael Ventnor]

(In reply to comment #7)
> I would prefer to have markup (not js) based tests but it seems "indeterminate"
> is available from script only. There is no "indeterminate" attribute?

Correct, this is how its defined in HTML5 and also how it works in Webkit.

Comment 11

[alexander :surkov (:asurkov)]

(In reply to comment #8)

> I didn't see any problem with events. When focused on a partially checked
> checkbox and pressing SPACE, like on the test page, the state goes to "not
> checked", which may be specific to this scenario.

If I get right we should fire mixed state change event.

Comment 12

[alexander :surkov (:asurkov)]

Comment on attachment 361277 [details] [diff] [review]
Patch with mochitest

r=me

please file following up bugs.

Comment 13

[Marco Zehe (:MarcoZ)]

Pushed in changeset:
http://hg.mozilla.org/mozilla-central/rev/61880bdd4594

Comment 14

[alexander :surkov (:asurkov)]

Marco, I see you filed bug 477975 for actions, should this bug be used for a11y state change events or do you plan to file new one?