Re: Significant ambiguities in aria-roledescription

Birkir,

For SVG and canvas based graphics, I would not include diagrams and graphs
in the use case at this time. I can see using roledescription as an
affordance to cue in users on what interactivity is available in a graphic;
but I don't like roledescription for describing a non-interactive 'slice'
of pizza, that may be better expressed by a title, desc(ription) or a
different aria property.

                                                              
     Regards,                                                 
                                                              
    Fred Esch                                                 
 Watson, IBM, W3C                                             
  Accessibility                                               
                                                              
 IBM Watson       Watson Release Management and Quality       
                                                              






From:	Birkir Gunnarsson <birkir.gunnarsson@deque.com>
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>
Date:	07/09/2016 03:43 PM
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