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

James Nurthen wrote:
>Remember that wcag is not just for screen reader users. 
>There are potentially issues for users with cognitive disabilities as well as potential issues for screen magnifier users 
>if focus gets moved when checking a checkbox. 

I was specifically questioning the notion that users need advanced notice if a checkbox opens a dialog. And, for the reasons I provided, I doubt we have evidence that any person with any kind of disability would derive benefit from advanced notice when a checkbox opens a dialog. In fact, I am arguing that there is an equal chance that advanced notice will impair perception of the content of the UI for many users.

If we do not have evidence from research, can anyone spell out a specific scenario that demonstrates how a specific class of people would experience problems because a checkbox opens a dialog when checked? Consider the mute implementation I mentioned. Instead of implementing the ARIA checkbox markup, a 100% WCAG-proof approach would have been to give the element that opens the mute dialog role button and aria-lable of "Mute ...". Then, if the conversation is muted, the label would become "Unmute". I did not press engineering for such a change to the ARIA markup in that UI because I couldn't identify any real-world advantage for any class of user that would have been gained from the work. If someone can identify such an advantage, then I would gladly make sure that developers never trigger a dialog from a checkbox state change.

On the other hand, I completely agree that a checkbox that jumps focus to another part of the page will, in nearly all cases, create issues that clearly violate the WCAG intent and cause problems for some people.

Matt

-----Original Message-----
From: James Nurthen [mailto:james.nurthen@oracle.com] 
Sent: Wednesday, February 3, 2016 8:23 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>; Birkir Gunnarsson <birkir.gunnarsson@deque.com>; public-aria@w3.org
Subject: Re: Why is aria-expanded invalid with a checkbox?

Matt,
Remember that wcag is not just for screen reader users. There are potentially issues for users with cognitive disabilities as well as potential issues for screen magnifier users if focus gets moved when checking a checkbox. 

Regards,
James. 

> On Feb 3, 2016, at 17:54, 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 -
> 
> 
> 
>

Received on Thursday, 4 February 2016 08:20:30 UTC