W3C home > Mailing lists > Public > public-aria@w3.org > February 2016

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

From: Matt King <a11ythinker@gmail.com>
Date: Wed, 3 Feb 2016 17:54:23 -0800
To: "'Richard Schwerdtfeger'" <richschwer@gmail.com>, "'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>
Message-ID: <00e001d15eee$f8eddaa0$eac98fe0$@Gmail.com>
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.


-----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. 


> 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 01:54:56 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:19 UTC