Re: Question about aria-roledescription in the 1.1 spec

Matt, 

While I agree this is one viewpoint, other screen readers like JAWS want to convey both. For example, if a listbox and options are represented as a pie with slices they will want to convey that this is a listbox with options in addition to the role description. 

Others, like VoiceOver operate the way you suggest. I can see both sides as in the case of the listbox the slices really are roles and not labels and if a teacher is referring to the pizza in the classroom the user will want to know where it is. However, at the same time they want to know that it operates like a listbox with options. Otherwise, they don’t quite know how to operate it. 

In other cases, it makes no sense to separate them out. Because of this I would not want to be overly prescriptive in the ARIA spec. as to what screen reader vendors should do. Another option is to speak the role description first and say that it works like a listbox. It is verbose and you would not want to say it all the time. There are different strategies for doing it. 

Rich

Rich Schwerdtfeger




> On Oct 7, 2016, at 2:54 PM, Matt King <a11ythinker@gmail.com> wrote:
> 
> Rich,
> 
> It seems the area of dispute/concern is whether a screen reader should
> announce the underlieing role in addition to the roledescription. The intent
> of the spec is NO they should not. The screen reader should only use the
> underlieing role to generate interaction help.
> 
> If some screen readers announce both underlieing role and roledescription,
> then roledescription is reduced to a label and has lost all its value. So,
> when working with the screen reader developers, we need to be consistent and
> clear on this point.
> 
> Matt
> 
> 
> -----Original Message-----
> From: Rich Schwerdtfeger [mailto:richschwer@gmail.com] 
> Sent: Friday, September 30, 2016 4:38 AM
> To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
> Cc: ARIA Working Group <public-aria@w3.org>
> Subject: Re: Question about aria-roledescription in the 1.1 spec
> 
> Bryan,
> 
> 1. The underlying role and label are still preserved with roledescripton. It
> should seldom be used unless absolutely necessary, such as what a reacher is
> referring to in a class (pie slice) on a role of option in a listbox. 
> 
> 2. Roles are already localized by ATs
> 
> This property must be used sparingly.
> 
> Rich
> 
> 
> 
> Sent from my iPad
> 
>> On Sep 29, 2016, at 5:03 PM, Bryan Garaventa
> <bryan.garaventa@ssbbartgroup.com> wrote:
>> 
>> Hi,
>> I've been reading through the spec because I have to write up internal
> guidelines for these things, and in reading aria-roledescription something
> jumped out at me.
>> 
>> Historically we've always said to developers don't put the role of an
> element in a label, like so:
>> 
>> <button aria-label="Attachment button"></button>
>> 
>> So, I'm not clear on how this is meant to be different, here is an excerpt
> from the 1.1 spec for aria-roledescription:
>> 
>> The following examples show the use of aria-roledescription to indicate
> that a button in a web-based email client is associated with an
> "attachment."
>> 
>> Example 27
>> <div role="button" tabindex="0" aria-roledescription="attachment 
>> button">family_reunion.jpg</div> Example 28 <button 
>> aria-roledescription="attachment button">family_reunion.jpg</button>
>> 
>> http://www.w3.org/TR/wai-aria-1.1/#h-aria-roledescription
>> 
>> So is the guidance always for the use of this attribute to reflect the
> underlying role? What happens if developers don't?
>> 
>> 
>> 
>> Bryan Garaventa
>> Accessibility Fellow
>> SSB BART Group, Inc.
>> bryan.garaventa@ssbbartgroup.com
>> 415.624.2709 (o)
>> www.SSBBartGroup.com
>> 
>> 
>> 
> 
>