RE: Why is aria-expanded invalid with a checkbox?

Birkir,

I think your example demonstrates why it is logical for the spec to allow aria-expanded on checkbox.

Note that it already works and that at least JAWS dutifully announces both state changes. I didn't try NVDA or VoiceOver.

That said, because there is no focus change, and because the new content is later in the reading order, the page would comply with WCAG with or without aria-expanded.

Determining whether aria-expanded on that checkbox has a measurable impact on usability for PwD would require study. I would be willing to bet that it wouldn't be measurable.

However, I am certain there is a usability advantage gained by having the checkbox show/hide the relevant options.

Matt


-----Original Message-----
From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com] 
Sent: Wednesday, February 3, 2016 6:45 PM
To: Matt King <a11ythinker@gmail.com>
Cc: Richard Schwerdtfeger <richschwer@gmail.com>; Joseph Scheuhammer <clown@alum.mit.edu>; Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; Stefan Schnabel <stefan.schnabel@sap.com>; James Nurthen <james.nurthen@oracle.com>; public-aria@w3.org
Subject: Re: Why is aria-expanded invalid with a checkbox?

Bringing the conversation back to my original question once more (I won't keep doing it, I just want to add a few points of clarification).
I coded a dummy scenario similar to what I have frequently seen lately:
http://a11yideas.com/testcode/checkboxContent_after.html

Most checkboxes do not cause sections of content to appear when they are checked, that is not expected behavior for a checkbox.

But in complex forms it is common practice to only show users content that is relevant to their choices, it makes the form easier to perceive and interact with.
In my example the special accommodation checkbox opens up a section of the form asking about the kinds of accommodations desired when checked.
Users who don't need it don't want to see it. It could confuse them.
Implimenters don't want to use the screen real-estate to display info that is only relevant in certain scenarios.

If the checkbox was a button or a link, the recommendation would be to use aria-expanded on the triggering element to show the state of the visible content controled by that element (aka accordions).
Since it is not the default behavior of a checkbox to cause content to appear, I thought aria-expanded should communicate same info.

An aria-controls relationship is only communicated when the content is visible on the page. Screen readers sometimes offer a hotkey to go to the controlled content from the triggering element. If that section is hidden, that would only confuse the user.
If we think about equal experiences:

A sighted user instantly sees content appear and disappear as he toggles the checkbox.
Shouldn't we communicate the same to users who do not see the screen, especially when it can be done with a single attribute?
Sure, we can use clipped text, or the title attribute, or a live region. But if this were a button or a link, the  aria-expanded attribute is the standard solution.
Isn't it logical to recommend the same attribute for a checkbox that triggers  the same functionality?
We could discuss how applicable <a
href="http://www.w3.org/WAI/GL/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html">WCAG
SC 3.2.2</a> is to this scenario.
Strict interpretation has caused me not to call this a change of context as long as the content appears after the triggering element.

But it is still an inferior user experience if you don't see the change.

I am a relative newbie to the exciting but complex world of ARIA, and am excited to have access to the people who invented the thing. I have a lot to learn.
But I do a lot of work out in the trenches and want to bring in the scenarios I face in my day-to-day work that I think ARIA could and should address.
So I rest my case and will, of course, respect the decision of the group and not recommend improper use of ARIA.
Thanks
-Birkir







On 2/3/16, Matt King <a11ythinker@gmail.com> wrote:
> All modern screen readers handle focus changes into dialogs in a very 
> graceful manner. Well designed dialogs are very easy to close, and 
> correctly coded dialog cancellation returns focus to the element that 
> opened the dialog. So, we have an intuitive "undo my mistake" affordance.
>
> Users do not get advanced warning of error dialogs, and they seem to 
> handle those.
>
> In other words, I am questioning the notion that 3.3.2 dictates the 
> user needs to be told in advance that a dialog is going to open if an 
> element is activated. If a user would struggle with this particular 
> behavior, it is not likely the user has any idea what a dialog is. 
> And, I would place a large bet that such a user has no idea that "..." means that a dialog will open.
>
> So, does anyone have user testing data to suggest that we are not 
> "creating a problem from thin air?"
>
> Sometimes I think we tend to overcode accessibility and overwhelm 
> users with meta information that makes the real information harder to perceive.
>
> Matt
>
> -----Original Message-----
> From: Richard Schwerdtfeger [mailto:richschwer@gmail.com]
> Sent: Wednesday, February 3, 2016 11:11 AM
> To: Joseph Scheuhammer <clown@alum.mit.edu>
> Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; Stefan 
> Schnabel <stefan.schnabel@sap.com>; Birkir Gunnarsson 
> <birkir.gunnarsson@deque.com>; James Nurthen 
> <james.nurthen@oracle.com>; public-aria@w3.org
> Subject: Re: Why is aria-expanded invalid with a checkbox?
>
> Ellipses are always a good indicator of a dialog box. I don’t recall 
> seeing one on a checkbox. I could see one on a form submittal. I have 
> seen them on pushbuttons.
>
> Rich
>
>> On Feb 3, 2016, at 1:02 PM, Joseph Scheuhammer <clown@alum.mit.edu>
>> wrote:
>>
>> On 2016-02-03 12:28 PM, Bryan Garaventa wrote:
>>> I understand this in most cases, and if the group decides this is 
>>> the best way to go, that's fine with me.
>>>
>>> However I do need to explain the situation, because the circumstance 
>>> I'm referring to was more unique, in that the client is a financial 
>>> institution that was sued because it did not adiquatly convey to 
>>> non-sighted screen reader users that the checking of a particular 
>>> checkbox would significantly impact there accounts, even though this 
>>> was conveyed visually using CSS for sighted users.
>>>
>>> So the legal design requirements were then mandated that it must 
>>> convey that something else was going to happen when this checkbox was checked.
>>>
>>> As I said, if the group decides this association is not important, 
>>> I'll refer them to this thread in the future to explain why.
>>
>> The typical way to indicate that a dialog is going to be invoked is 
>> via ellipses, "...". For example, the ellipsis in a "Save as ..." 
>> menu item tells me that I'm about get a save-file dialog.  I know 
>> that one screen reader, Orca, speaks "ellipsis" when one navigates to 
>> menu items with ellipses.
>>
>> Would adding an ellipsis to a check box label workl?  Admittedly it 
>> looks a bit odd:
>>
>> [ ] Click to accept these terms ...
>>
>> Another thought:  although it does overload the label, what about 
>> adding text to the checkbox itself, such as:
>>
>> [ ] Click to accept these terms (will show a confirmation dialog).
>>
>> --
>> ;;;;joseph.
>>
>> 'Die Wahrheit ist Irgendwo da Draußen. Wieder.'
>>                 - C. Carter -
>>
>
>
>
>


--
Birkir R. Gunnarsson
Senior Accessibility Subject Matter Expert | Deque Systems
2121 Cooperative Way, Suite 210
Herndon, VA, 20171

Ph: (919) 607-27 53
Twitter: @birkir_gun

Received on Thursday, 4 February 2016 08:56:51 UTC