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 <http://www.w3.org/html/wg/drafts/html/master/>


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