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

> On Apr 30, 2014, at 9:19 PM, Shane McCarron <shane@aptest.com> wrote:
> 
> Thanks for your explanation.  I am sorry that my example seemed convoluted - it is actually something I do already in an app (custom roles using vocabularies) because I use @role for other sorts of client-side processing. 
> 
> I don't want to derail this conversation.  If the task of this new attribute is to provide a replacement name for the role (as opposed to a description of the role) then yes, aria-roledescription is a bad name.
> 
> role has fallback rules.  If I use role="shane:customRole text group othernonsense" then the ARIA role is group in ARIA 1.0, and might be text in ARIA 1.1 (yes, I know you wouldn't say a group was text - not important).  

Correct.

> I assume you envision that aria-customrolename="my custom role name" would replace whatever role was chosen by the ARIA implementation - not just the first one.  And that there would be no way to provide custom names for each of the four roles I mentioned in my example.  Right?

Potentially you’ll be able to call Element.computedRole() and determine which ARIA token role was applied, and then provide a custom name based on that knowledge. That said, I can’t immediately think of a scenario you would need to conditionally choose the loc string.


>> On Wed, Apr 30, 2014 at 10:47 PM, James Craig <jcraig@apple.com> wrote:
>> 
>> No, this isn't right, or your example was too contrived to be understandable. We're talking about the localized role string that the user hears. For example, a site like SlideShare or Keynote for iCloud may wish to indicate that a particular group is a slide. Currently they would only be able to do this. Note: example uses aria-label instead of aria-labelledby for brevity only.
>> 
>>   <div role="group" aria-label="Quarterly Report">
>> 
>> This would result in the user hearing something like "Quarterly Report, group." While that's fine, there is benefit in differentiating different types of groups. So authors sometimes put the role description in the label, such as:
>> 
>>   <div role="group" aria-label="Quarterly Report, slide">
>> 
>> This would result in the user hearing a duplicated localized role name like "Quarterly Report, slide, group." Ideally it'd be better to do something like this (attr name TDB):
>> 
>>   <div role="group" aria-customrolename="slide" aria-label="Quarterly Report">
>> 
>> The UA and AT would treat the role as a standard group, but allow the user to hear something more useful yet less verbose like "Quarterly Report, slide." Several platform APIs have matching API. OS X's AX API calls this "AXRoleDescription", the Microsoft UIA property is called "LocalizedControlType."
>> 
>> 
>> On Apr 30, 2014, at 6:33 PM, Shane McCarron <shane@aptest.com> wrote:
>> 
>> > I am afraid we are running off into the weeds here...  You can already use any 'role' name you want.  Isn't the point of this to provide an extended description of a custom role?  If I have some amazing custom widget (like the next big image carousel selector) I might use role="shane:myNavigableCollection group".  An AT would get the role of group.  We want a way to more clearly tell the user that while this is a group, it is a *special* group.  aria-roledescription="Shane's amazing collection navigator" seems to make perfect sense to me.
>> >
>> > Or did I get this completely wrong?
>> >
>> >
>> > On Wed, Apr 30, 2014 at 7:21 PM, James Craig <jcraig@apple.com> wrote:
>> > "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
>> > >>>
>> > >>
>> >
>> >
>