Re: ISSUE-636 ACTION-1398 Provide spec. text for aria-roledescription

Would aria-altrolename work?
Suggesting this is an alternative name for the role?
Was trying to get away from such a long name for the attribute but also 
capture the idea that utilization of this attribute is an alternative that 
may be useful to some AT in the same way that alt text is more useful. 
Also captures the need for localization because most people realize that 
alt text is somethat needs to be localized.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   James Craig <jcraig@apple.com>
To:     Richard Schwerdtfeger/Austin/IBM@IBMUS, 
Cc:     Birkir Gunnarsson <birkir.gunnarsson@deque.com>, Steve Faulkner 
<faulkner.steve@gmail.com>, W3C WAI Protocols & Formats 
<public-pfwg@w3.org>
Date:   05/02/2014 01:29 PM
Subject:        Re: ISSUE-636 ACTION-1398 Provide spec. text for 
aria-roledescription



On May 2, 2014, at 1:13 PM, Richard Schwerdtfeger <schwer@us.ibm.com> 
wrote:
I would definitely not want to add a role name on top of a role 
description. Developers are going to go nuts over having to keep track of 
all these permutations. We need to keep this simple. 
We’re not talking about two attribute names. Just one. Some people 
objected to the verbiage “description” so we’re discussing alternate 
proposals. 

We are creating a localized more detailed version of the role. It is 
essentially a localized subclass that is author defined. Let's focus on 
that. In early GUI days we often referred to user defined controls or 
classes. What I would prefer to see, if we were going to change this, 
would be userRole or authorRole which should be defined as a localized 
author/user defined subclass of the supplied role. 
We should be careful to not refer to this as a subclass. That implies a 
lot more than this string provides. The names “userRole” and “authorRole” 
also imply that we’re changing the role, which we’re not. We’re only 
changing a string the user hears when encountering this element. What 
about “role string” or “custom role string"?

This, to me, makes more sense. It should also be a failure to have 
userRole or authorRole (whichever we might pick) without the presence of a 
non-abstract role attribute.
I agree it should be a warning, but think it would be useful to rely on 
implicit roles sometimes.

Also, removing name and description from the attribute name avoids 
confusion with name and descriptions which are already in ARIA which is 
what I believe was Birkir's concern earlier. 
That’s fair, but “user role” and “author role” aren’t right either. 
aria-rolestring? aria-customrolestring?

James

Rich



Rich Schwerdtfeger

<graycol.gif>James Craig ---04/30/2014 07:21:46 PM---"Type" isn't right. 
This isn't the type. It's just the user presented string. I don't like 
"rolelabe

From: James Craig <jcraig@apple.com>
To: Birkir Gunnarsson <birkir.gunnarsson@deque.com>, Steve Faulkner <
faulkner.steve@gmail.com>
Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, W3C WAI Protocols & Formats <
public-pfwg@w3.org>
Date: 04/30/2014 07:21 PM
Subject: Re: ISSUE-636 ACTION-1398 Provide spec. text for 
aria-roledescription



"Type" isn't right. This isn't the type. It's just the user presented 
string. I don't like "rolelabel" either, but think we could consider 
"aria-rolename" in addition to "aria-roledescription"…

"Custom" is already implied but might be useful. Although long, "custom 
role name" (@aria-customrolename) is probably the most clear of any attr 
names we've discussed.


On Apr 30, 2014, at 5:46 AM, Birkir Gunnarsson <
birkir.gunnarsson@deque.com> wrote:

> What about
> Aria-controltype
> Or
> Aria-customcontroltype
> 
> (I don´t like desc or description, because elsewhere it is used for the 
context of the control, not to describe the control itself).
> Also we need to discourage this role from being used by authors in lieu 
of properly applying semantics for supported widgets.
> End users are confused enough by inconsistent implementation of various 
widgets and often have a hard time understanding how to properly interact 
with them (just take tabs for example).
> 
>> From: Steve Faulkner [mailto:faulkner.steve@gmail.com] 
>> Sent: Wednesday, April 30, 2014 6:55 AM
>> To: James Craig
>> Cc: Richard Schwerdtfeger; W3C WAI Protocols & Formats; Shane McCarron
>> Subject: Re: ISSUE-636 CTION-1398 Provide spec. text for 
aria-roledescription
>> 
>> bikeshedding on name
>> 
>> why not rolelabel ?
>> 
>> its short, it better describes what it is, when 'description' is used I 
think 2 things:
>> 
>> longer text string and additional information
>> 
>> --
>> 
>> Regards
>> 
>> SteveF
>> HTML 5.1
>> 
>> 
>> On 1 April 2014 00:18, James Craig <jcraig@apple.com> wrote:
>>> Sorry for not clarifying, but the action to propose spec text doesn't 
mean formatted HTML, but just some text like I've reformatted yours below. 
The idea is to get the discussion going.
>>> 
>>> On Mar 30, 2014, at 4:00 PM, Richard Schwerdtfeger <schwer@us.ibm.com> 
wrote:
>>> 
>>>> aria-roledesc (property)
>>>> Provides a human readable, localized string name for the role of the 
element. The role of the element MUST have a computed value of group or 
region to apply aria-roledesc.
>>>> Note: The computed role of the element is localized by applicable 
assistive technologies. The aria-roledesc property provides a mechanism 
for the author to provide that localized string in its place.
>>>> Used in Roles: group, region
>>>> Value: string
>>>> 
>>> 
>>> 
>>> Individual comments listed below.
>>> 
>>>> aria-roledesc (property)
>>> 
>>> We've been avoiding abbreviation as it leads to ambiguity and lack of 
clarity. I would either prefer the longer "aria-roledescription" or the 
longer "localized role name" that Cynthia suggested. I avoided the term 
"localized" because Brits spell it "localised"… We already have the 
labelledby/labeledby misspellings due to colloquial differences; let's 
don't add another.
>>> 
>>>> Provides a human readable, localized string name for the role of the 
element.
>>> 
>>> This should use the term "Defines" not "Provides". The rest of the 
value attributes use this terminology, including the string value 
attributes like these.
>>> 
>>> http://www.w3.org/WAI/PF/aria/complete#aria-label

>>> http://www.w3.org/WAI/PF/aria/complete#aria-valuetext

>>> 
>>> Other attributes use different terms in the description. "Identifies" 
for IDREF and IDREFS, "Indicates" for boolean-like attributes, etc. I just 
realized these terms weren't codified anywhere in the spec, so I've added 
ACTION-1416: Include definitions for terms used as first word of all attr 
definitions (defines, identifies, indicates, etc.)
>>> 
>>> 
>>>> The role of the element MUST have a computed value of group or region 
to apply aria-roledesc.
>>> 
>>> All RFC-2119 statements should define the actor. In other words, "To 
whom does this requirement apply?" In this case, I think you likely meant 
"web authors" so I would rephrase this as two RFC-2119 requirements.
>>> 
>>> 1. User Agents MUST NOT expose the value of aria-roledescription 
unless the element has a computed role value of group or region.
>>> 2. In order to use aria-roledescription, authors MUST assign the 
element a role value of group or region.
>>> 
>>> But the more I look at this, the more I think authors will misuse it 
if we limit the functionality this severely. For example, with the rules 
above, we'd almost be encouraging authors to use the group role just so 
they could get a custom role name, even on interactive elements where a 
more appropriate role applies e.g. <div role="group" 
aria-roledescription="super button">foo</div> Here, even though we were 
trying to prevent them from breaking user expectation on interactive 
controls
>>> 
>>> What if instead we make the suggestion much less restrictive, and 
explain the reasons in prose.
>>> 
>>> 1. User Agents MUST NOT expose the value of aria-roledescription if an 
explicitly defined ARIA role is not provided by the author.
>>> 2. Authors MUST only use aria-roledescription on elements with an 
explicitly defined role attribute containing a valid ARIA role.
>>> 3. Authors MUST localize the value of aria-roledescription.
>>> 4. Authors SHOULD avoid assigning custom role value to interactive 
elements. In other words, don't override the role description of standard 
controls like button or slider.
>>> 
>>> Prose follow in-between triple quotation marks:
>>> """
>>> Users of assistive technologies learn interaction patterns based on 
localized role descriptions such as "button" or "adjustable". When authors 
change that end-user role description, users may no longer the intention 
of the control, or how to operate it. Custom role descriptions are only 
recommendation for use on non-interactive group container roles like group 
or region. One might use this on an group container to indicate that it is 
a "slide" in a web-based slide presentation software.
>>> 
>>> Example:
>>> 
>>> <div role="region" aria-roledescription="slide" id="slide42" 
aria-labelledby="slide42heading">
>>>         <h1 id="slide42heading">Quarterly Report</h1>
>>>         <!-- remaining slide contents -->
>>> </div>
>>> 
>>> In the previous example, a screen reader user may hear "Quarterly 
Report, slide" rather than the more vague usage in ARIA 1.0 "Quarterly 
Report, region" or "Quarterly Report, group"
>>> 
>>> """
>>> 
>>>> Note: The computed role of the element is localized by applicable 
assistive technologies. The aria-roledesc property provides a mechanism 
for the author to provide that localized string in its place.
>>>> 
>>>> Used in Roles: group, region
>>>> Value: string
>>> 
>>> localized string
>>> 
>>