RE: Significant ambiguities in aria-roledescription

Rich,

Short comment:

>>> The accessibility tree will not change because of a role description and we would not want it to…

According to actual Core Accessibility Mapping<http://w3c.github.io/aria/core-aam/core-aam.html> of aria-roledescription<http://w3c.github.io/aria/aria/aria.html#aria-roledescription> , at least UIA LocalizedControlType will be overwritten:

ARIA 1.1] aria-roledescription<http://w3c.github.io/aria/aria/aria.html#aria-roledescription>

MSAA + IAccessible2

Expose the description string in IAccessible2 localizedExtendedRole property.

UIA

Localized Control Type is <value>.

ATK/AT-SPI

Expose the description string in object attribute roledescription:<value>.

AXAPI

AXRoleDescription: '<value>'.


This will  therefore not change the UIA ControlType but the LocalizedControlType value which is typically used as announced string  in any screen reader using UIA interfaces, I think.

The problem here is that the human-audible role string is coming from LocalizedControlType and never from ControlType (which is an AutomationType and not a String).

So you are maybe right that the acc.  tree is not altered, but the effect of overwriting  may be nevertheless there and screen readers must be aware of it not taken this for given but offer the chance to access always  the original LocalizedControlType on request if someone is interested in the real role description. Those subtle things count.

Regards
Stefan




From: Richard Schwerdtfeger [mailto:richschwer@gmail.com]
Sent: Donnerstag, 7. Juli 2016 15:43
To: White, Jason J <jjwhite@ets.org>
Cc: Matt King <a11ythinker@gmail.com>; ARIA Working Group <public-aria@w3.org>
Subject: Re: Significant ambiguities in aria-roledescription

s
On Jul 7, 2016, at 8:33 AM, White, Jason J <jjwhite@ets.org<mailto:jjwhite@ets.org>> wrote:



From: Richard Schwerdtfeger [mailto:richschwer@gmail.com]
Sent: Thursday, July 7, 2016 9:11 AM
Matt,

While I understand your point, the group’s job is not to design the screen readers for them.
[Jason] Although it could be argued that Matt’s second point is overly prescriptive of screen reader behavior, his first point concerns what user agents disclose to the accessibility API where role=none and aria-roledescription is non-empty. I think the role value is (or ought to be) controlling in this situation. My quick review didn’t identify a statement in the draft that would address the point, but I haven’t conducted a thorough review outside the section on aria-roledescription and the section on role=none. I’m content to leave the text as is if we think it’s sufficiently clear as it stands, but neither would I object to the addition of an explanatory statement.

What we expose is important. The accessibility tree will not change because of a role description and we would not want it to. We need to have the AT be able to go back to the underlying role  type and structure so that they know how to operate with it. We can address this in the accessibility api mappings.

The role description is nothing more than a localized role type that may be spoken by the ATs. When I was working with Freedom Scientific on role description earlier they were not crazy about but certainly in areas like education it is critical so that the student and teacher can be talking about the same thing. e.g. a list and listems could be pizza and slices. They still need to know that it is a list.

At the end of the day we can’t possibly, with any consistency, use the role description to alter the accessibility tree. It is a localized string and frankly could be anything the author wants.

Rich



________________________________
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.