Re: ACTION-2092 - Proposal ready for review - Create a proposal for handling the role description value of ""

Matt, 

The decision to support roledescription has already been made. We also have platform mappings. Both iOS and MacOSX have had support for a role description for years. 

We are going to put this up for a straw poll. 

I will say, that if you vote for 3 and we have to reopen the text/static role issue you will delay ARIA, potentially, for weeks. 

Your proposal in (2) does say that screen readers may choose to not speak the role. That is a MAY. 

I do not think it is a good idea to hold up ARIA in HTML 5.1 and SVG2 for weeks for this. 

Rich
 
> On Jul 6, 2016, at 5:38 AM, Matt King <a11ythinker@gmail.com> wrote:
> 
> Stefan,
>  
> The intent is that screen readers speak the roledescription in place of the role. My option 3 makes this part more clear by placing a requirement on assistive tehcnologies.
>   <>
> If authors misuse roledescription as described in the spec, the problems you describe will arise. However, you should note the other assistive technology requirement I included in option 3 that tells screen readers that they should not change any function other than the element announcement based on the roledescription value. That is, if the element is a button, it should be in the button list even if the roledescription is “link”.
>  
> When I shared this with Jamie Teh, he preferred option 3. However, he pointed out that there are some elements where screen readers suppress the speaking of the role. For example, screen readers do not say “list item” when reading through a list. So, in such cases, should the screen reader be free to ignore the roledescription if specified? Or, should the screen reader be required to speak the roledescription?
>  
> Matt
>  
> From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com] 
> Sent: Wednesday, July 6, 2016 1:40 AM
> To: Matt King <a11ythinker@gmail.com>; 'Rich Schwerdtfeger' <richschwer@gmail.com>
> Cc: 'ARIA Working Group' <public-aria@w3.org>
> Subject: RE: ACTION-2092 - Proposal ready for review - Create a proposal for handling the role description value of ""
>  
> Hi Matt,
>  
> I’d like to ask (using concrete examples) how the actual Core Accessibility Mapping <http://w3c.github.io/aria/core-aam/core-aam.html> of aria-roledescription <http://w3c.github.io/aria/aria/aria.html#aria-roledescription> will influence the “native” role detection. 
>  
> Characteristics:
> Characteristic
> Value
> Used in Roles:
> All elements of the base markup
> Value:
> string <http://w3c.github.io/aria/aria/aria.html#valuetype_string>
>  
>  
> ARIA 1.1] aria-roledescription <http://w3c.github.io/aria/aria/aria.html#aria-roledescription>
> MSAA + IAccessible2
> Expose the description string in IAccessible2 localizedExtendedRole property.
> UIA
> Localized Control Type is <value>.
> ATK/AT-SPI
> Expose the description string in object attribute roledescription:<value>.
> AXAPI
> AXRoleDescription: '<value>'.
>  
>  
> With other words, what will be the expected speech output on element focus (including role, value, label and other) according to the current CAM when testing the code below on all platforms above?
>  
> For instance, in UIA, I expect role identification override issues when the mapping remains as  currently. Also, I am not sure if every role/ roledescription combination has already been pre-evaluated for potential conflicts. IMHO, it is also important to separate clearly between what can be done in the UA Mapping and what are the “additional” expectations  that AT has to fulfil. The latter should not remain lugubrious.
>  
> 1)  <button aria-roledescription=”emphasized”>Save</button>
> 2)  <button aria-roledescription=””>Save</button>
> 3)  <button aria-roledescription=” ”>Save</button>
> 4)  <button aria-roledescription=”link”>Save</button>
>  
> 5)  <label for=”i1”>Amount</label><input id=”i1” aria-roledescription=”extended” value=”20”/>
> 6)  <a href=”(http ref) aria-roledescription=”button”>More Info</a>
> 7)  <span role=”alert” aria-roledescription=”I am a something type of error” aria-label=”Something happened”/>
> 8)  <span role=”application” aria-roledescription=”I am a custom something”/>
>  
> I think the discussion will benefit from when we are distinct here and willing to actively scan for potential contradictions. 
> I can do more examples on request. 
>  
> Best Regards
> Stefan
>  
>  
>  
> From: Matt King [mailto:a11ythinker@gmail.com <mailto:a11ythinker@gmail.com>] 
> Sent: Mittwoch, 6. Juli 2016 00:09
> To: 'Rich Schwerdtfeger' <richschwer@gmail.com <mailto:richschwer@gmail.com>>
> Cc: 'ARIA Working Group' <public-aria@w3.org <mailto:public-aria@w3.org>>
> Subject: RE: ACTION-2092 - Proposal ready for review - Create a proposal for handling the role description value of ""
>  
> Option 1 and 3 both specify that a value that is empty or only white space does exactly that; it does not change the processing of the element b/c the roledescription is not exposed.
>  
> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com <mailto:richschwer@gmail.com>] 
> Sent: Tuesday, July 5, 2016 2:51 PM
> To: Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com>>
> Cc: ARIA Working Group <public-aria@w3.org <mailto:public-aria@w3.org>>
> Subject: Re: ACTION-2092 - Proposal ready for review - Create a proposal for handling the role description value of ""
>  
> … or you leave the role description off altogether and the default is to do nothing (don’t change how the role is processed). 
>  
> I do agree there is a concern that authors will put themselves in a position where they try to be the screen reader vendor and influence the user experience. 
>  
>  
> Rich Schwerdtfeger
>  
>  
> 
>  
>> On Jul 5, 2016, at 4:27 PM, Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com>> wrote:
>>  
>> I vote for option 3 in the below proposal. If option 3 is not acceptable to the group, I vote for option 1.
>>  
>> While allowing ARIA to wipe out screen reader announcement of an element’s role with an empty roledescription makes ARIA more flexible, I think it is unnecessary flexibility that increases the risk of negative side effects and makes debugging problems more complex for authors. As a screen reader user, I already find roledescription scary enough without this added complexity.
>>  
>> Matt King
>>  
>> From: Matt King [mailto:a11yThinker@Gmail.com <mailto:a11yThinker@Gmail.com>] 
>> Sent: Tuesday, July 5, 2016 1:53 PM
>> To: ARIA Working Group <public-aria@w3.org <mailto:public-aria@w3.org>>
>> Subject: ACTION-2092 - Proposal ready for review - Create a proposal for handling the role description value of “”
>>  
>> Proposals to specify how null or empty aria-roledescription values will be handled by user agents and assistive technologies are ready for review.
>>  
>> Following are the proposals. As I explain below, I think this exposes other ambiguities in aria-roledescription that should be plugged.
>>  
>> In branch action2092option1[1], added the following sentence.
>> "If the value of aria-roledescription is empty or contains only white space characters, user agents MUST treat the element as if the aria-roledescription property were not specified."
>>  
>> In branch action2092option2[2], added the following 2 sentences.
>> "If the value of aria-roledescription is empty or contains only white space characters, user agents SHOULD expose the value in a manner consistent with how null values are expressed in their platform accessibility API. If the value is empty or null, assistive technologies MAY render the element as if it does not have a role name."
>>  
>> In the process of making the above branches, I noticed that there is still significant ambiguity regarding what an assistive technology should do with the roledescription. The actual intent of the property is not clear. For example, if you provide a roledescription for a region, should the assistive technology still treat the element as a region? This ambiguity also has significant impact on the meaning of the note that tells authors how to limit the use of roledescription.
>>  
>> The issue of how authors, user agents, and assistive technologies may treat null or empty values increases the need to remove these ambiguities. So, I have also proposed an option 3, which equivalent to option 1 but also addresses these issues. I did not make a similar equivalence to option 2 because it is much less clear what the normative authoring and assistive technology guidance should be in that case.
>>  
>> In branch action2092option3[3]:
>> 1. Stated that user agents MUST NOT expose aria-roledescription if it is empty or whitespace (same as option 1)
>> 2. Changed the note that contained an implied normative author SHOULD limiting use of the roledescription into a normative author SHOULD.
>> 3. Added a normative assistive technology SHOULD statement explaining that roledescription should change only how the name of the role of an element is expressed and should not change which assistive technology functions are provided for an element.
>> 4. (editorial) Used a list format to express the authoring and user agent requirements.
>>  
>> [1] action2092option1 branch:
>> http://rawgit.com/w3c/aria/action2092option1/aria/aria.html <http://rawgit.com/w3c/aria/action2092option1/aria/aria.html>
>>  
>> [2] action2092option2 branch:
>> http://rawgit.com/w3c/aria/action2092option2/aria/aria.html <http://rawgit.com/w3c/aria/action2092option2/aria/aria.html>
>>  
>> [3] action2092option3 branch:
>> http://rawgit.com/w3c/aria/action2092option3/aria/aria.html <http://rawgit.com/w3c/aria/action2092option3/aria/aria.html>
>>  
>> Matt King