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

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

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.

Rich



Rich Schwerdtfeger



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