Re: Significant ambiguities in aria-roledescription

Hi Matt, 

These are editorial comments I would like to address when the group reviews the pseudo last call draft. IOW, we should not hold up the pseudo last call draft for these. 

You are very optimistic Matt. I don’t know that we can prevent widespread abuse of many features we have. We certainly can make it better. I do hope , however that our authoring practices do not limit expectations to screen reading. ARIA is much more than that. 

Rich


> On Jul 11, 2016, at 2:27 AM, Matt King <a11ythinker@gmail.com> wrote:
> 
> Look at the complete roledescription text and the examples. The attachment button example makes it clear that the author may want to include the word button in the roledescription. On the other hand, consider the example I described in the test scenario … in that case you would not want to include the role name in the role description. A property like this is useless if it doesn’t give authors a reasonable degree of freem and responsibility.
>   <>
> It is possible we could make the text even more clear so people who associate the same connotations with “description” that you associate with it are not confused.
>  
> Clear spec text combined with robust authoring guidance, something we didn’t have with ARIA 1.0,  should allow the ARIA working group to introduce new features without the same concerns of wide spread abuse and misinterpretations that were associated with several features of ARIA 1.0.
>  
> At some point, screen reader developers will need to stop second guessing every author out there or even perfectly coded web pages will suck for their users. I think there are much better ways for screen readers to help their users cope with pages where authors messed up … they shouldn’t automatically degrade good pages for the sake of the few bad ones.
>  
> I think this is quite different from user agent treatment of null values. As you know, it is extremely common, and reasonable given the way most other ARIA properties are processed, for authors to assume that null property values do not have side effects.
>  
> Matt
>  
> From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com>] 
> Sent: Friday, July 8, 2016 10:36 PM
> 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
>  
> Yes, when I say suppress, I’m referring to what you then describe as the following:
>  
> “In a situation like this, it would be much, much nicer if words like slider, listbox, grid, or application  were never spoken automatically. Of course, the actual roles could still be available via a “where am I” or context help  type of command.”
>  
> This is actually the same behavior that you are opposed to with regard to using aria-roledescription=”” to suppress the role of image, but in this case you are suppressing the role of other interactive widget roles and replacing it with the string in aria-roledescription instead. Also, Rich already said during the meeting that Freedom Scientific has already refused to do this, saying that this would be too confusing for their users if no underlying role was conveyed, so if this is the intent of the spec text it is already going to be ignored.
>  
> Also I disagree that the spec text is already clear about this, reading as follows:
>  
> "The aria-roledescription property gives authors the ability to override how assistive technologies localize and express the name of a role. Thus, inappropriately using aria-roledescription may inhibit users' ability to understand or interact with an element. Authors SHOULD limit use of aria-roledescription to clarifying the purpose of non-interactive container roles like group or region or to providing a more specific description of a widget."
>  
> So the first part of this refers to the name of a role, but the end refers to the description of a role. The meaning between a role name and a role description is actually quite different.
>  
> E.G I interpret the name of a role as defining it’s type, analygous to its mapping, such as button, checkbox, radio, etc. A description however describes what a role does, “Press Enter or Space to activate”, “Press Left or Right to navigate”, “Press Enter to submit”, etc.
>  
> How too is this supposed to work if applied to structural elements like <table>, <dl>, <ul>, <ol>, etc., where all of these include semantic child element roles that need to remain exposed regardless? E.G How will a user know what a table is if the word ‘table’ as it’s primary role is not announced, no matter what the accessibility tree contains.
>  
> Earlier I think you or somebody else mentioned that this isn’t supposed to happen like this, however that is exactly what the spec text says:
>  
> "The aria-roledescription property gives authors the ability to override how assistive technologies localize and express the name of a role.”
>  
> This would make it necessary for implementors in the table example to have to use the word “table” within the aria-roledescription attribute simply to comply with the spec and convey that this is a table, causing double repetition within ATs like screen readers that refuse to ignore the role and announce both the role and the aria-roledescription attribute string.
>  
> I understand the use case as you outlined it, however the risk is too great to make this type of thing so widely implementable that it can screw up everything else.
>  
>  
>  
> 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 4:49 PM
> To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.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
>  
> Bryan, when you say suppress, are you talking only about announcement?
>  
> The spec is very clear that roledescription is not the role; it is an author-supplied, localized name for the role. It is only that. The role of the element is not changed in the accessibility tree and all role based functionality provided by assistive technologies should be retained.
>  
> The spec language and examples are also reasonably clear that roledescription is the localized name of the role of the element so it would be repetitive for a screen reader to automatically voice both its own localized version of the role name in addition to the author supplied role description. It is useful to think of this feature of the property in the context of the kinds of examples Mark described at TPAC.
>  
> Imagine the following instructions in a test:
>  
> “use the up and down arrow keys to highlight a slice of the pie and then press right arrow to increase the size or left arrow to decrease the size of the highlighted slice. When a slice is the size you desire, you can freeze its size by pressing space. Portion the pie to represent blab la bla “
>  
> To get the screen reader to drop into application mode, the pie could be a listbox, single column grid, or application element. The slices could be horizontal sliders that toggle their read only state with the spacebar. 
>  
> In a situation like this, it would be much, much nicer if words like slider, listbox, grid, or application  were never spoken automatically. Of course, the actual roles could still be available via a “where am I” or context help  type of command.
>  
> With the strong wording we have in the spec and good authoring guidance, I think we can fend off overuse and just plain idiocy to a sufficiently reasonable extent. I have been convinced there are important use cases for this property. And, just like aria-label and aria-labelledby, it requires care in its use or users will be harmed.
>  
> Matt
>  
> From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com>] 
> Sent: Friday, July 8, 2016 3:55 PM
> 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.
>