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

I think there needs to be some form of registry for aria-roledescription
 values, otherwise its going to be the wild west.

--

Regards

SteveF
HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>


On 1 April 2014 01:03, James Craig <jcraig@apple.com> wrote:

>
> Another example we could add to the spec is the EPUB chapter, including
> the namespaced or prefixed roles like the epub stuff.
>
> <!-- First token "epub:chapter" not recognized as a valid ARIA role, so
> UAs should expose fallback "group" role, and still speak "chapter" role
> description. -->
> <div role="epub:chapter group" aria-roledescription="chapter" id="intro"
> aria-labelledby="c1h1">
>         <h1 id="c1h1">Introduction</h1>
>         <!-- remaining chapter contents -->
> </div>
>
>
> On Mar 31, 2014, at 4:18 PM, 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
> >
> >
>
>
>