825114 - Checkable state should not be exposed for ARIA buttons with aria-pressed

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

Str:
1. Create an ARIA toggle button with the following code: <div role="button" aria-pressed="true" tabindex="-1">Test</div>
2. Examine its accessible states.
Expected: The checkable state should not be exposed.
Actual: The checkable state is exposed.

I understand why checkable is being exposed, as this is a control which can be toggled. However, there is confusion about what "checkable" means and how to distinguish these cases. Because checkable can be exposed on any control, NVDA interprets checkable to mean that the checked state is significant. In practical terms, it says "not checked" if checkable is present but checked is not. In this case, the significant state is actually pressed, not checked. As a result, NVDA says "not checked" for a pressed button, which is quite misleading.

If the checkable state is really intended to mean "toggleable", we need to know which states to expect in various cases; e.g. toggle buttons use pressed, but all other controls used checked.

So, there are two possible solutions to this bug:
1. Stop exposing checkable on ARIA toggle buttons; or
2. Rename checkable to togglable and clearly document the expected states for various cases.

Comment 1

[alexander :surkov (:asurkov)]

Both, ATK and IA2 provide roles for toggle buttons (ATK_ROLE_TOGGLE_BUTTON and IA2_ROLE_TOGGLE_BUTTON) which are used when aria-pressed is defined on role="button". If checkable object attribute is rather misleading then it doesn't seem we need anything else.

Note, UAIG says it should be exposed. This behavior was implemented in bug 477876. Also we just followed UAIG (see bug 477876 comment #10).

Comment 2

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #1)
> Note, UAIG says it should be exposed. ... Also we just followed UAIG (see bug 477876 comment #10).
Is there someone we can ask as to why UAIG requires this? Surely checkable instead of pressable or togglable is misleading when the relevant property is aria-pressed.

Comment 3

[alexander :surkov (:asurkov)]

I sent a question http://lists.w3.org/Archives/Public/wai-xtech/2013Jan/0001.html

Comment 4

[Samuel Joehl]

When the aria-checked state is not specified on an object, the default value on a checkable object is "undefined," such as on objects with role=button where aria-checked is not a valid state:
http://www.w3.org/TR/wai-aria/states_and_properties#aria-checked

The problem is that the checked state that is being exposed on a checkable object even when aria-checked has not been specified is "not checked," causing NVDA to announce this state. If the checkable state is "undefined," then AT should be able to ignore the checked state of the object since by definition "undefined" means that the object is not checkable. AT should have a way to query for the undefined value and ignore any checkable attributes exposed if the "undefined" value is set.

Comment 5

[alexander :surkov (:asurkov)]

Samuel, thank you for commenting here. As I understand we have a problem with aria-pressed but you say about aria-checked. Is it another problem or you confused aria-pressed with aria-checked?

Comment 6

[James Teh [:Jamie]]

(In reply to Samuel Joehl from comment #4)
> The problem is that the checked state that is being exposed on a checkable
> object even when aria-checked has not been specified is "not checked,"
> causing NVDA to announce this state.
ATs don't deal with ARIA directly. There is no "not checked" state. "Not checked" is indicated by the absence of the checked state and the presence of the checkable state. The problem is as I stated above: Firefox exposes checkable on buttons with aria-pressed.

Comment 7

[Samuel Joehl]

(In reply to alexander :surkov from comment #5)
> Samuel, thank you for commenting here. As I understand we have a problem
> with aria-pressed but you say about aria-checked. Is it another problem or
> you confused aria-pressed with aria-checked?
When aria-checked is not specified on an object (such as role=button) the default value is "undefined." Since buttons are being exposed through a checkable object attribute, the object is reporting a state of "unchecked" which is being announced by NVDA. For checkable object attributes assistive technologies should have a method to query a checkable object to determine if the checked state has been specified and if not (value of "undefined"), ignore the fact that the object is checkable. This would solve the problem not only for buttons but any other object which may potentially be checkable but has not been defined as such by the author by not specifying the aria-checked property. I realize there may be IA2/ATK limitations but my opinion is that the "undefined" value should be returned so that potential checkable state can be ignored.

Comment 8

[James Teh [:Jamie]]

(In reply to Samuel Joehl from comment #7)
> For checkable object attributes assistive
> technologies should have a method to query a checkable object to determine
> if the checked state has been specified and if not (value of "undefined"),
> ignore the fact that the object is checkable.
The point is that buttons *shouldn't* be considered checkable. There's no way to specify undefined, as I explained in comment 6. Checkable can be exposed dynamically based on whether aria-checked is true or false (among other rules).

Comment 9

[alexander :surkov (:asurkov)]

(In reply to Samuel Joehl from comment #7)
> (In reply to alexander :surkov from comment #5)
> > Samuel, thank you for commenting here. As I understand we have a problem
> > with aria-pressed but you say about aria-checked. Is it another problem or
> > you confused aria-pressed with aria-checked?
> When aria-checked is not specified on an object (such as role=button) the
> default value is "undefined."

aria-checked is not applicable to role="button" so if you do <div role="button" aria-checked=something/> then aria-checked is completely ignored as it wasn't there.

Can you give me please a code snippet and say where is a problem?

Comment 10

[Samuel Joehl]

<code><img aria-disabled="false" style="border: 2px solid rgb(171, 0, 160);" id="p1" class="toolbarButton" onmouseover="AddChildFocus(1)" title="Play" role="button" aria-pressed="false" onmouseout="ClearChildFocus()" onclick="appCommands.PlayQueue()" alt="Play" src="img/button_play.gif"></code> from http://queuemusic.org. Using FF and NVDA, "play button not checked" is announced regardless of button pressed state because NVDA is unable to query object to determine that the value of the checkable object should be "undefined" as aria-checked was not defined for what maps to a checkable object in FF.

Comment 11

[Marco Zehe (:MarcoZ)]

Can we get back to this? <div role="button" aria-pressed="true">Press me!</div> should not have the checkable state exposed, since a button is pressable, but not checkable.

I was contacted by the author of TinyMCE WYSIWYG editor about this today, and even though the spec might say we need a checkable state on a toggle button, I believe the spec should be changed / enhanced. Hearing NVDA say "Press me! Toggle Button pressed not checked" just does not make any sense at all.

Comment 12

[alexander :surkov (:asurkov)]

pls confirm that no checkable object attribute on toggle button is all is needed?

Comment 13

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #12)
> pls confirm that no checkable object attribute on toggle button is all is
> needed?
That is one option, probably the simpler one.

The other is to rename checkable to togglable and clearly document the expected states for various cases; see comment 0. For example, it might be documented that if the role is toggleButton and the togglable state is present, we should look for the pressed state, not the checked state. This would need to be accepted by the IA2 and ATK communities.

Comment 14

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #13)

> The other is to rename checkable to togglable and clearly document the
> expected states for various cases; see comment 0. For example, it might be
> documented that if the role is toggleButton and the togglable state is
> present, we should look for the pressed state, not the checked state. This
> would need to be accepted by the IA2 and ATK communities.

what is usecase for toggable obj attr? toggable button should have toggle_button role (vs push_button).

Comment 15

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #14)
> what is usecase for toggable obj attr? toggable button should have
> toggle_button role (vs push_button).
That makes sense, though it's worth noting that the IA2 spec says IA2_ROLE_TOGGLE_BUTTON shouldn't be used. They say to just use ROLE_SYSTEM_PUSHBUTTON. I'd argue this deprecation should probably be removed, since otherwise, you can't tell whether a button is togglable when it's not pressed.

The reason we have the checkable attribute for the checked state is that checked can apply to quite a few roles. The question is whether the pressed state can apply to multiple roles. If it can't, then, as you say, we don't need a togglable/pressable state on toggle buttons.

Comment 16

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #15)
> (In reply to alexander :surkov from comment #14)
> > what is usecase for toggable obj attr? toggable button should have
> > toggle_button role (vs push_button).
> That makes sense, though it's worth noting that the IA2 spec says
> IA2_ROLE_TOGGLE_BUTTON shouldn't be used. They say to just use
> ROLE_SYSTEM_PUSHBUTTON. I'd argue this deprecation should probably be
> removed, since otherwise, you can't tell whether a button is togglable when
> it's not pressed.

agree, it's confusing

> The reason we have the checkable attribute for the checked state is that
> checked can apply to quite a few roles. The question is whether the pressed
> state can apply to multiple roles. If it can't, then, as you say, we don't
> need a togglable/pressable state on toggle buttons.

it seems it's applicable to buttons only http://www.w3.org/TR/wai-aria/states_and_properties#aria-pressed

Comment 17

[alexander :surkov (:asurkov)]

IA2 request to allow toggle_button: http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2014-February/001839.html

ARIA issue to remove 'checkable' requirement: https://www.w3.org/WAI/PF/Group/track/issues/645

I think we should be ok with legal stuff and can proceed with implementation.

Comment 18

[Marco Zehe (:MarcoZ)]

Yura, have you looked at this at all yet? I am just now working on semi-related bug 989958 and could adjust that one, too. It's only an adjustment in the ARIAMap I think.

Comment 19

[Marco Zehe (:MarcoZ)]

Yura, I'm "stealing" this one from you because I will be dealing with it in bug 989958.

Comment 20

[Marco Zehe (:MarcoZ)]

Fixed by push for bug 989958: https://hg.mozilla.org/integration/mozilla-inbound/rev/f1f9fc68fcf4

Comment 21

[Marco Zehe (:MarcoZ)]

Fixed by bug 989958, which landed on m-c: https://hg.mozilla.org/mozilla-central/rev/f1f9fc68fcf4

Comment 22

[Marco Zehe (:MarcoZ)]

Verified that this was fixed by bug 989958, and the fix landed in Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0.