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

... which brings us back to aria-haspopup (diabolic grin) with better explanation what waits in the dark jungle along the path for you ...

I think aria-describedby will do the trick, we should elaborate on Rich's proposal.

- Stefan

Sent from my iPad

On 03.02.2016, at 20:25, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:

I agree, but not in the logic that providing no method for doing something like indicating the presence of something that opens a dialog is desirable.

Providing no provision for something means that developers that need to do so have to fall back on offscreen text, because there is no other cross platform automatically localizable method for doing this otherwise.



Ideally we could use the method documented in the ARIA 1.1 bug at

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25851



But I haven't seen any action on this in a long time.

From: Matt King [mailto:a11ythinker@gmail.com]
Sent: Wednesday, February 03, 2016 11:18 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>; 'James Nurthen' <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>; 'Richard Schwerdtfeger' <richschwer@gmail.com<mailto:richschwer@gmail.com>>
Cc: 'Stefan Schnabel' <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>; 'Birkir Gunnarsson' <birkir.gunnarsson@deque.com<mailto:birkir.gunnarsson@deque.com>>; public-aria@w3.org<mailto:public-aria@w3.org>
Subject: RE: Why is aria-expanded invalid with a checkbox?

A checkbox that causes content to be added/removed later in the reading order, as long as it does not move focus, would never be a violation of 3.2.2.

Aria-expanded is allowed on button, and is quite useful in sections that expand/collapse. The definition of aria-expanded says it can be used on an element that controls expansion. I personally think the best way to code a clickable section title that expands/collapses is like …

<H2><button aria-expanded=”false”>Title of my section</button></h2>

Then, when reading by heading, all in one shot, I can hear that the section is expandable, the title of the section, and the fact that it currently collapsed. I don’t have to move my reading cursor to expand it – just press enter and continue reading.

A similar paradigm with checkbox seems equally valid to me. However, I wouldn’t put a checkbox inside of a heading. But, the example that Birkir initially presented seems completely valid.

I would also argue that a checkbox that opens a dialog might be, but is not always, a violation of 3.2.2.

I do not see any value in adding aria-controls, aria-expanded, or aria-haspopup on a checkbox that opens a dialog. Based on their definitions, I do not think any of them are appropriate.

If you want to see an example of a checkbox that opens a dialog, open a conversation in www.messenger.com<http://www.messenger.com>. There is a checkbox labeled “Mute”. If you check it, a dialog of “Mute options” opens where you can choose to mute for 30 min, a day, forever, … If you cancel out of the dialog, focus returns to the checkbox and it remains unchecked. If you choose to mute, focus returns to the checkbox and it is checked. Technically this checkbox causes a change in context, but it does not cause any of the orientation issues described in the 3.2.2 success criteria. It is very different from say moving focus to a set of radio buttons that would be displayed inline further down the page. Since a dialog opens, the user can immediately and easily learn that cancelling goes right back to the checkbox.

Evaluating 3.2.2 can be very tricky, and I think it requires informed judgment in order to follow its intent. It is easy to squash a lot of perfectly good UX ideas with it. It is always useful to remember why it exists in the first place … think back to the ‘90s when people were making comboboxes that move focus with onchangeevent.

Matt

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Wednesday, February 3, 2016 10:38 AM
To: James Nurthen <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>; Richard Schwerdtfeger <richschwer@gmail.com<mailto:richschwer@gmail.com>>
Cc: Stefan Schnabel <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>; Birkir Gunnarsson <birkir.gunnarsson@deque.com<mailto:birkir.gunnarsson@deque.com>>; public-aria@w3.org<mailto:public-aria@w3.org>
Subject: RE: Why is aria-expanded invalid with a checkbox?

Ah yes.

“3.2.2 On Input: Changing the setting of any  user interface component  does not automatically cause a  change of context  unless the user has been advised of the behavior before using the component.”
https://www.w3.org/WAI/GL/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html

We still do need to have a viable solution for this type of implementation in the wild.


From: James Nurthen [mailto:james.nurthen@oracle.com]
Sent: Wednesday, February 03, 2016 10:24 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>; Richard Schwerdtfeger <richschwer@gmail.com<mailto:richschwer@gmail.com>>
Cc: Stefan Schnabel <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>; Birkir Gunnarsson <birkir.gunnarsson@deque.com<mailto:birkir.gunnarsson@deque.com>>; public-aria@w3.org<mailto:public-aria@w3.org>
Subject: Re: Why is aria-expanded invalid with a checkbox?

Unless you are warned in advance that it is going to happen IMO this is a WCAG failure under 3.2.2

Regards,
James
On 2/3/2016 10:22 AM, Bryan Garaventa wrote:

That sounds fine for a custom design.



I do wish to point out that the checkbox triggers dialog is a common paradigm that has been around for many years however

https://www.google.com/search?site=&source=hp&q=checkbox+that+opens+dialog&oq=checkbox+that+opens+dialog&gs_l=hp.3..33i21l2.3206.11374.0.11736.33.30.2.1.1.0.198.3257.9j21.30.0....0...1c.1.64.hp..0.23.2607.0.rr7M8kdIOdY

So it would be nice if we could all agree on a specific design pattern for dealing with this.







-----Original Message-----
From: Richard Schwerdtfeger [mailto:richschwer@gmail.com]
Sent: Wednesday, February 03, 2016 9:59 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com><mailto:bryan.garaventa@ssbbartgroup.com>
Cc: Stefan Schnabel <stefan.schnabel@sap.com><mailto:stefan.schnabel@sap.com>; Birkir Gunnarsson <birkir.gunnarsson@deque.com><mailto:birkir.gunnarsson@deque.com>; James Nurthen <james.nurthen@oracle.com><mailto:james.nurthen@oracle.com>; public-aria@w3.org<mailto:public-aria@w3.org>
Subject: Re: Why is aria-expanded invalid with a checkbox?



I see. So that can be done in a number of ways:



- A live region with an aria-describedby that points to it from the control. Content would be triggered upon focus change. ( I like this as it can be changed and the user is guaranteed to be notified)

- A confirmation popup when a form is submitted. There may be multiple form elements that require a notification to the user.



Rich



> On Feb 3, 2016, at 11:28 AM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> 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.

>

>

>

> -----Original Message-----

> From: Richard Schwerdtfeger [mailto:richschwer@gmail.com]

> Sent: Wednesday, February 03, 2016 9:06 AM

> To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>

> Cc: Stefan Schnabel <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>; Birkir Gunnarsson

> <birkir.gunnarsson@deque.com<mailto:birkir.gunnarsson@deque.com>>; James Nurthen

> <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>; public-aria@w3.org<mailto:public-aria@w3.org>

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

>

> In this case even the sighted user does not know that is what is going to happen. This is just a confirmation. There is no reason to have to indicate that it has a popup.

>

> So, what happens:

>

> a dialog gets generated

> an AT gets notified that a dialog was generated Focus moves to the dialog box. The AT reads the dialog and the description if coded right.

>

> This is far different from a drop down menu where you have a button with a drop down that you need to operate to make a choice. The user will have a visual indication that the button has a dropdown (like a visible down arrow). That is not the case with a confirmation dialog.

>

> … sorry, no reason to have a popup on that.

>

> Rich

>

>> On Feb 3, 2016, at 10:46 AM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:

>>

>> A devil's advocate question, what happens if you have a checkbox that when checked, opens a confirmation dialog?

>>

>> This is a real world example, for a legal requirement of a client, where checking the checkbox involved important ramifications that needed to be conveyed to the user.

>>

>> Technically the two actions are separate, the checking of the checkbox, which is either true or false, and the expantion of a content layer that must be associated to convey the importance of understanding this action.

>>

>> How should these be linked? The use of aria-controls is not reliable, aria-owns is not valid.

>>

>> -----Original Message-----

>> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com]

>> Sent: Wednesday, February 03, 2016 4:01 AM

>> To: Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>>

>> Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>; Birkir

>> Gunnarsson <birkir.gunnarsson@deque.com<mailto:birkir.gunnarsson@deque.com>>; James Nurthen

>> <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>; public-aria@w3.org<mailto:public-aria@w3.org>

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

>>

>> No way would I want an expandable checkbox. It should fail a validator.

>>

>> Browsers let things like this pass because it is too expensive to correct every possible poorly coded web page. They need to try to be performant. This is a validator issue.

>>

>> Rich

>>

>> Sent from my iPad

>>

>>> On Feb 3, 2016, at 1:42 AM, Schnabel, Stefan <stefan.schnabel@sap.com<mailto:stefan.schnabel@sap.com>> wrote:

>>>

>>> To be used in which pattern? Collapse/Expand of regions?

>>>

>>> Regards

>>> Stefan

>>>

>>> -----Original Message-----

>>> From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]

>>> Sent: Mittwoch, 3. Februar 2016 00:39

>>> To: Birkir Gunnarsson <birkir.gunnarsson@deque.com<mailto:birkir.gunnarsson@deque.com>>; James Nurthen

>>> <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>

>>> Cc: public-aria@w3.org<mailto:public-aria@w3.org>

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

>>>

>>> I vote we just add this role to the spec, it already works.

>>>

>>> E.G

>>>

>>> <input type="checkbox" aria-expanded="true" title="Test" />

>>>

>>> This already sets the 'expanded' state in IE11, Firefox, and Chrome in the accessibility tree.

>>>

>>> -----Original Message-----

>>> From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com]

>>> Sent: Tuesday, February 02, 2016 3:27 PM

>>> To: James Nurthen <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>

>>> Cc: public-aria@w3.org<mailto:public-aria@w3.org>

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

>>>

>>> As a screen reader, if I move to a checkbox and hear:

>>> "I hold a non immigrant visa, checkbox not checked collapsed"

>>> (<input type="checkbox" aria-expanded="false" aria-controls="niv">

>>> <div role="region" aria-label="None Immigrant Visa information"

>>> id="niv">

>>>

>>> ...

>>> </div>

>>>

>>> I would know that checking that checkbox will cause additional content to appear.

>>>

>>> You are right that aria-controls hints at the same thing, but it is not necessarily tied to the display of a section of content.

>>> It could be a submit button that becomes enabled only after I check the checkbox.

>>> It could also be a section that is already visible on the page but checking the checkbox automatically changes default UI element settings.

>>>

>>> the use of aria-expanded would clearly tell me that a section of the page will be expanded or collapsed as a result of me interacting with the checkbox, the non-visual equivalent of seeing content appear and disappear.

>>>

>>> I am just perplexed why aria-expanded is allowed on so many roles, (I have some difficulty seeing the use cases for some of them), but not on a check box.

>>> Cheers

>>>

>>>

>>>

>>>> On 2/2/16, James Nurthen <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>> wrote:

>>>> I'd have thought that checked in combination with aria-controls was

>>>> enough here.

>>>> Unless the checked and expanded state can be different (which I

>>>> don't believe they could be) I would just use checked and aria-controls.

>>>>

>>>>> On 2/2/2016 2:58 PM, Birkir Gunnarsson wrote:

>>>>> Oh wise ones.

>>>>>

>>>>> I am working with a team that is implementing a form where

>>>>> checking a check box expands a section further down the page.

>>>>> They actually thought of putting aria-expanded and aria-controls

>>>>> on the check box to communicate this info to assistive technologies.

>>>>> I had to stop the because checkbox role is not one of the 40 or so

>>>>> roles that allow the aria-expanded property.

>>>>>

>>>>>

>>>>> I find this curious.

>>>>> The situation I described, where sections of a dynamic form or

>>>>> webpage are displayed or hidden in response to user checking or

>>>>> unchecking a check box is quite common.

>>>>> Sure, if the section of the page is, in content order, after the

>>>>> checkbox that controls it, users do not necessarily need to be

>>>>> aware of the change, but it is a very smart usability decision to

>>>>> inform the user that checking a checkbox affects contents

>>>>> elsewhere on the webpage.

>>>>> My questions are:

>>>>> 1. Why was aria-expanded not considered a valid attribute with

>>>>> check boxes and, 2. Can this case be revisited? If so I'd be happy

>>>>> to create an issue ticket if necessary.

>>>>> Thanks

>>>>> -Birkir

>>>>

>>>> --

>>>> Regards, James

>>>>

>>>> Oracle <http://www.oracle.com>

>>>> James Nurthen | Principal Engineer, Accessibility

>>>> Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415

>>>> 987

>>>> 1918 <tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>

>>>> <sip:james.nurthen@oracle.com> Oracle Corporate Architecture

>>>> 500 Oracle Parkway | Redwood Cty, CA 94065 Green Oracle

>>>> <http://www.oracle.com/commitment> Oracle is committed to

>>>> developing practices and products that help protect the environment

>>>

>>>

>>> --

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

>>>

>



--
Regards, James

<image001.gif><http://www.oracle.com>
James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781<tel:+1%20650%20506%206781> | Mobile: +1 415 987 1918<tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood Cty, CA 94065
<image002.gif><http://www.oracle.com/commitment>Oracle is committed to developing practices and products that help protect the environment