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 Saturday, 9 July 2016 16:39:52 UTC