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

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