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

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



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