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

There is always some degree of anything happens in a UI. The issue is whether it is important to know about it. In the case of a dialog that confirms your setting it is not an issue. 

If it is something like “this is going to cause you to make a purchase”. For that we are looking at things in COGA that would drive consistent user style information that could cause an API mapping. There is no accessibility api mapping for things like that. 

We need to be pragmatic. 

Rich

> On Feb 3, 2016, at 11:23 AM, Schnabel, Stefan <stefan.schnabel@sap.com> wrote:
> 
> OK .. However, the diabolic question remains unanswered.
> 
> It is then  the "click here and it can happen anything" pattern .. or can it have some more refinement?
> 
> Apart from saying that state changes never should trigger dialogs popping up?
> 
> Regards
> Stefan
> 
> -----Original Message-----
> From: Richard Schwerdtfeger [mailto:richschwer@gmail.com] 
> Sent: Mittwoch, 3. Februar 2016 18:06
> To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
> Cc: Schnabel, Stefan <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?
> 
> 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> 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>
>> Cc: Bryan Garaventa <bryan.garaventa@ssbbartgroup.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?
>> 
>> 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> 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>; James Nurthen 
>>> <james.nurthen@oracle.com>
>>> Cc: 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>
>>> Cc: 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> 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 
>>>> <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
>>> 
>

Received on Wednesday, 3 February 2016 17:42:46 UTC