Re: Significant ambiguities in aria-roledescription

Yes and we should not be confusing role stings with computed names and descriptions (part of Matt’s previous comments). To me, the biggest mess with MSAA when it came out was the guidance was dreadful as was the documentation. So, people were putting semantics in buckets where the did not belong. For example, roles were stuffed in names and vice versa. What made it even worse was people were sticking custom role strings in the role itself due to the way it was designed. This was a 1.0 version of arguably the first platform accessibility API. We should learn from those mistakes and not repeat them. 

Another thing we need to do is circle back with EO. A lot of great work has been put into the APG. We need to make sure it is disseminated better this go around. 

Rich


> On Jul 11, 2016, at 2:43 AM, Schnabel, Stefan <stefan.schnabel@sap.com> wrote:
> 
> All,
>  
> either way, as part of the APG, we need a clear guideline with good examples what is a valid *custom role string*for aria-roledescription and what is rather a *label string*.  
> 
> Otherwise, much confusion will be the result.
>  
> Best Regards
> Stefan
>  
> From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com>] 
> Sent: Samstag, 9. Juli 2016 00:55
> To: Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com>>; 'White, Jason J' <jjwhite@ets.org <mailto:jjwhite@ets.org>>; 'ARIA Working Group' <public-aria@w3.org <mailto:public-aria@w3.org>>
> Subject: RE: Significant ambiguities in aria-roledescription
>  
> I am really not in favor of using this attribute to suppress the role of any implicit or explicit ARIA role, it is guaranteed to be misused like this.
>  
> Personally I think this attribute should be used in conjunction to the role, such as an object role being set via the role attribute, a name being set using the naming calculation, and the aria-roledescription string being added as the description of the object to supplement what is already set as the role and name.
>  
> The img role can be a special exception where if aria-roledescription is set to “”, then it ignores the image role for ATs as we spoke of yesterday, I don’t have a problem with that, but this would only be safe on images and not for all roles.
>  
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com>
> 415.624.2709 (o)
> www.SSBBartGroup.com <http://www.ssbbartgroup.com/>
>  
> From: Matt King [mailto:a11ythinker@gmail.com <mailto:a11ythinker@gmail.com>] 
> Sent: Friday, July 08, 2016 3:45 PM
> To: 'White, Jason J' <jjwhite@ets.org <mailto:jjwhite@ets.org>>; 'ARIA Working Group' <public-aria@w3.org <mailto:public-aria@w3.org>>
> Subject: RE: Significant ambiguities in aria-roledescription
>  
> Jason,
>  
> Matt wrote:
> ><img role=”none” aria-roledescription=”Gotch ya”>
> ><table role=”none” aria-roledescription=”layout table”>
> >What would end up in the AX tree? What should a screen reader say?
> Jason wrote:
> >This is indicative of an author error.
> >I think the tree should always reflect the value of the role attribute.
>  
> I agree that is probably reasonable, but our current spec language doesn’t lean in that direction.
>  
> Given this language…
> “User agents must not expose the aria-roledescription property if any of the following conditions exist.
> 1. The element to which aria-roledescription is applied does not have a valid WAI-ARIA role or does not have an implicit WAI-ARIA role semantic.
> …” <>
>  
> Is role=”none” a valid ARIA role?
>  
> And this authoring requirement:
>  
> “When using aria-roledescription, authors should also ensure that:
> 1.       The element to which aria-roledescription is applied has a valid WAI-ARIA role or has an implicit WAI-ARIA role semantic.
> …”
>  
> Should authors think of role=”none” as valid?
>  
> Matt
>  
> From: White, Jason J [mailto:jjwhite@ets.org <mailto:jjwhite@ets.org>] 
> Sent: Thursday, July 7, 2016 5:59 AM
> To: Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com>>; ARIA Working Group <public-aria@w3.org <mailto:public-aria@w3.org>>
> Subject: RE: Significant ambiguities in aria-roledescription
>  
>  
>  
> From: Matt King [mailto:a11ythinker@gmail.com <mailto:a11ythinker@gmail.com>] 
> Sent: Thursday, July 7, 2016 4:18 AM
> 
> Ambiguity #1: role none with a role description:
> <img role=”none” aria-roledescription=”Gotch ya”>
> <table role=”none” aria-roledescription=”layout table”>
>  
> What would end up in the AX tree? What should a screen reader say?
> [Jason] This is indicative of an author error. I think the tree should always reflect the value of the role attribute.
>  
> Ambiguity 2:  role description on an element whose role is normally suppressed by screen readers:
> <ul>
> <li aria-roledescription=”fruit”>Apple</li>
> <li aria-roledescription=”fruit”>Banana</li>
> <li aria-roledescription=”fruit”>Orange </li>
> </ul>
>  
> Should screen readers be expected to announce each list item as a fruit? Or, should the screen reader be able to use normal processing for the listitem role and not speak the role description?
> [Jason] Given that the author specified aria-roledescription, most likely for a legitimate reason, it should be honored in this case. However, it shouldn’t override the implications of the actual role as given in the role attribute, which is why role=”none” should be respected in the content of the accessibility tree.
>  
>  
> This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.
> 
>  
> Thank you for your compliance.
>