RE: Significant ambiguities in aria-roledescription

Matt

Screen reader with brains! Sounds delicious!
I know, we have the "social handshake" going on between webpage authors, assistive technologies and end users.
We still have not managed to make it work effectively for things such as semantic text elements (<strong> <em> etc.). So, you are right, there are challenges.

-----Original Message-----
From: Matt King [mailto:a11ythinker@gmail.com] 
Sent: Monday, July 11, 2016 3:59 AM
To: 'Birkir Gunnarsson' <birkir.gunnarsson@deque.com>; tink@tink.uk
Cc: 'Bryan Garaventa' <bryan.garaventa@ssbbartgroup.com>; 'Schnabel, Stefan' <stefan.schnabel@sap.com>; 'Richard Schwerdtfeger' <richschwer@gmail.com>; 'White, Jason J' <jjwhite@ets.org>; 'ARIA Working Group' <public-aria@w3.org>
Subject: RE: Significant ambiguities in aria-roledescription

When a property is that complex for users to exploit, it starts losing its value.

On the other hand, if a significant number of important web sites start abusing the property, screen reader developers in particular will end up doing something like this without being asked to do so.

However, I think abetter approach for screen reader developers would be to watch for commonly abused properties or other types of ARIA mistakes and then dynamically include options for intelligent reconfiguration of the screen reader for that page in the context help for the page. .... just imagine it ... screen readers with brains.

Matt

-----Original Message-----
From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com]
Sent: Saturday, July 9, 2016 12:43 PM
To: tink@tink.uk
Cc: 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>; ARIA Working Group <public-aria@w3.org>
Subject: Re: Significant ambiguities in aria-roledescription

I think if this role goes through, a recommendation to assistive technologies would be not to expose the aria-roledescription in default mode.
Users should explicitly have to switch to a different mode to enable aria-roledescription to override roles.
If the strongest set of use cases for this role come from the educational sector, they can include recommendations for screen reader users on how to active the appropriate mode.
I ahve a hard time imagining any useful cases for this in an everyday browsing experience case, but see where it could be useful for educational and online gaming sectors, possibly for complex interactive diagrams or graphs.


On 7/9/16, Léonie Watson <tink@tink.uk> wrote:
> 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
>
>


--
Birkir Gunnarsson, CPACC
Senior Accessibility Subject Matter Expert | Deque Systems
2121 Cooperative Way, Suite 210
Herndon, VA, 20171

Ph: (919) 607-27 53
Twitter: @birkir_gun

Received on Monday, 11 July 2016 10:18:48 UTC