RE: Significant ambiguities in aria-roledescription

Bryan, when you say suppress, are you talking only about announcement?

 

The spec is very clear that roledescription is not the role; it is an
author-supplied, localized name for the role. It is only that. The role of
the element is not changed in the accessibility tree and all role based
functionality provided by assistive technologies should be retained.

 

The spec language and examples are also reasonably clear that
roledescription is the localized name of the role of the element so it would
be repetitive for a screen reader to automatically voice both its own
localized version of the role name in addition to the author supplied role
description. It is useful to think of this feature of the property in the
context of the kinds of examples Mark described at TPAC.

 

Imagine the following instructions in a test:

 

"use the up and down arrow keys to highlight a slice of the pie and then
press right arrow to increase the size or left arrow to decrease the size of
the highlighted slice. When a slice is the size you desire, you can freeze
its size by pressing space. Portion the pie to represent blab la bla "

 

To get the screen reader to drop into application mode, the pie could be a
listbox, single column grid, or application element. The slices could be
horizontal sliders that toggle their read only state with the spacebar. 

 

In a situation like this, it would be much, much nicer if words like slider,
listbox, grid, or application  were never spoken automatically. Of course,
the actual roles could still be available via a "where am I" or context help
type of command.

 

With the strong wording we have in the spec and good authoring guidance, I
think we can fend off overuse and just plain idiocy to a sufficiently
reasonable extent. I have been convinced there are important use cases for
this property. And, just like aria-label and aria-labelledby, it requires
care in its use or users will be harmed.

 

Matt

 

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] 
Sent: Friday, July 8, 2016 3:55 PM
To: Matt King <a11ythinker@gmail.com>; 'White, Jason J' <jjwhite@ets.org>;
'ARIA Working Group' <public-aria@w3.org>
Subject: RE: Significant ambiguities in aria-roledescription

 

I am really not in favor of using this attribute to suppress the role of any
implicit or explicit ARIA role, it is guaranteed to be misused like this.

 

Personally I think this attribute should be used in conjunction to the role,
such as an object role being set via the role attribute, a name being set
using the naming calculation, and the aria-roledescription string being
added as the description of the object to supplement what is already set as
the role and name.

 

The img role can be a special exception where if aria-roledescription is set
to "", then it ignores the image role for ATs as we spoke of yesterday, I
don't have a problem with that, but this would only be safe on images and
not for all roles.

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com> 

415.624.2709 (o)

www.SSBBartGroup.com <http://www.SSBBartGroup.com> 

 

From: Matt King [mailto:a11ythinker@gmail.com] 
Sent: Friday, July 08, 2016 3:45 PM
To: 'White, Jason J' <jjwhite@ets.org <mailto:jjwhite@ets.org> >; 'ARIA
Working Group' <public-aria@w3.org <mailto:public-aria@w3.org> >
Subject: RE: Significant ambiguities in aria-roledescription

 

Jason,

 

Matt wrote:

><img role="none" aria-roledescription="Gotch ya">

><table role="none" aria-roledescription="layout table">

>What would end up in the AX tree? What should a screen reader say?

Jason wrote:

>This is indicative of an author error. 

>I think the tree should always reflect the value of the role attribute.

 

I agree that is probably reasonable, but our current spec language doesn't
lean in that direction.

 

Given this language.

"User agents must not expose the aria-roledescription property if any of the
following conditions exist.

1. The element to which aria-roledescription is applied does not have a
valid WAI-ARIA role or does not have an implicit WAI-ARIA role semantic.

."

 

Is role="none" a valid ARIA role?

 

And this authoring requirement:

 

"When using aria-roledescription, authors should also ensure that:

1.       The element to which aria-roledescription is applied has a valid
WAI-ARIA role or has an implicit WAI-ARIA role semantic.

."

 

Should authors think of role="none" as valid?

 

Matt

 

From: White, Jason J [mailto:jjwhite@ets.org] 
Sent: Thursday, July 7, 2016 5:59 AM
To: Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> >; ARIA
Working Group <public-aria@w3.org <mailto:public-aria@w3.org> >
Subject: RE: Significant ambiguities in aria-roledescription

 

 

 

From: Matt King [mailto:a11ythinker@gmail.com] 
Sent: Thursday, July 7, 2016 4:18 AM

Ambiguity #1: role none with a role description:

<img role="none" aria-roledescription="Gotch ya">

<table role="none" aria-roledescription="layout table">

 

What would end up in the AX tree? What should a screen reader say?

[Jason] This is indicative of an author error. I think the tree should
always reflect the value of the role attribute.

 

Ambiguity 2:  role description on an element whose role is normally
suppressed by screen readers:

<ul>

<li aria-roledescription="fruit">Apple</li>

<li aria-roledescription="fruit">Banana</li>

<li aria-roledescription="fruit">Orange </li>

</ul>

 

Should screen readers be expected to announce each list item as a fruit? Or,
should the screen reader be able to use normal processing for the listitem
role and not speak the role description?

[Jason] Given that the author specified aria-roledescription, most likely
for a legitimate reason, it should be honored in this case. However, it
shouldn't override the implications of the actual role as given in the role
attribute, which is why role="none" should be respected in the content of
the accessibility tree.

 

 

  _____  

This e-mail and any files transmitted with it may contain privileged or
confidential information. It is solely for use by the individual for whom it
is intended, even if addressed incorrectly. If you received this e-mail in
error, please notify the sender; do not disclose, copy, distribute, or take
any action in reliance on the contents of this information; and delete it
from your system. Any other use of this e-mail is prohibited.

 

Thank you for your compliance.

  _____