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

It works fine with NVDA in Firefox, but doesn't work with Voiceover.
My proposed change improves the screen reader user experience and is
consistent with the use of the aria-expanded attribute for other
controls in  same situation. It cannot be achieved using html alone.
It is already implemented in some browser interfaces.
I should not recommend an invalid attribute to the developers I work with.
Thanks
-Birkir


On 2/4/16, Matt King <a11ythinker@gmail.com> wrote:
> 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
>
>


-- 
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 13:14:59 UTC