RE: Significant ambiguities in aria-roledescription

Léonie,

All reasonable concerns. The question is whether we can adequately address them through spec language and strong authoring guidance. 

I did describe an example like the pizza one in this post ...
https://lists.w3.org/Archives/Public/public-aria/2016Jul/0071.html

This is NOT something I would widely promote, but we are at the cusp of experimental role extensibility with the combination of the re-written application role, aria-describedby, aria-roledescription, and aria-keyshortcuts.

Matt

-----Original Message-----
From: Léonie Watson [mailto:tink@tink.uk] 
Sent: Saturday, July 9, 2016 9:39 AM
To: Matt King <a11ythinker@gmail.com>; 'Bryan Garaventa' <bryan.garaventa@ssbbartgroup.com>; 'Schnabel, Stefan' <stefan.schnabel@sap.com>; 'Richard Schwerdtfeger' <richschwer@gmail.com>; 'White, Jason J' <jjwhite@ets.org>
Cc: 'ARIA Working Group' <public-aria@w3.org>
Subject: Re: Significant ambiguities in aria-roledescription

On 08/07/2016 21:18, Matt King wrote:
> Léonie, Bryan,
>
> I tried to address the ambiguities you are concerned about when working on action 2092. I replaced the non-normative "are only recommended for use" note with an "authors SHOULD." The following language is included in both of the drafts we are voting on in the CFC.
>
> "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."
>
> This paragraph is a strong foundation on which the authoring practices guide can build. I think it should cause any authors reading the spec to seriously consider how they are using the property. It also clarifies the meaning of "description".

Thanks Matt. Really appreciate the effort you're putting into clarifying things.

The thing that occured to me on Thursday's call, is that the use cases cited (originating from dPub I think), seem to be based on interactive components.

The one that was mentioned on Thursday was selecting slices of a pizza. 
The component would be something like a listbox, but there would be a disconnect between what sighted people saw (a pizza from which they could select a slice), and what screen reader users saw (a listbox from which they could choose an option). Hence th e need for aria-roledescription to provide a more helpful description of the component's purpose.

If this is a fair assessment (I'm still hunting for the examples provided by the dPub people), it seems the use case that prompted the invention of this attribute is the very thing the spec is now warning developers against using it for.

This, coupled with the inevitable loss of useful cues to interaction that will result when this attribute is used, troubles me greatly. What is a person supposed to do with a pizza exactly?

I think one solution to this (mentioned on the call) was for developers to provide help aimed specifically at screen reader users. This is ok on paper, but as we know from the "to tabpanel or not to tabpanel" debate recently, there is no easy way to provide that help, and few (if any) examples of it being provided successfully in the wild.

To all intents and purposes, aria-roledescription enables developers to create roles with no actual substance. I know the role of the thing in question remains unchanged, but that's irrelevant if the -roledescription conveys something else entirely to the user.

We're also opening up the possibility for people creating web components to create pseudo-roles for the things they create. It isn't what the role is intended for, but I suspect to many developers it's going to look very much like role extensibility.

Sorry, I know this has been discussed before, and that the attribute is in the spec, but looking closely at it now raises much concern in my mind.

Léonie.


--
@LeonieWatson tink.uk Carpe diem

Received on Monday, 11 July 2016 07:47:35 UTC