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 02:45:15 UTC