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

Rich Schwerdtfeger

James Craig <jcraig@apple.com> wrote on 03/31/2014 06:18:33 PM:

> From: James Craig <jcraig@apple.com>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: W3C WAI Protocols & Formats <public-pfwg@w3.org>, Shane McCarron
> <shane@aptest.com>
> Date: 03/31/2014 06:19 PM
> Subject: Re: ISSUE-636 CTION-1398 Provide spec. text for
aria-roledescription
>
> 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.
>
I would not be in favor of that as I keep hearing that "aria adds a lot of
weight to the page". This is also part of the reason we went from
presentation to none.

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

OK.

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

ok

>
> > 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.
>
Regarding 2 I would prefer the following text:

In order to use aria-roledescription, authors MUST ensure that the computed
role of the corresponding element has a 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
>

That is possible but at the same time I don't want them applying it to a
broad range of roles as they are more likely to get that wrong too.
We discussed this at the meeting.

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

We discussed this and Joanie, and me, both had issues with not being able
to search based on type and making something a SHOULD, on widgets, opens
the flood gates.
If you have a defined platform and a limited set of applications that would
be fine but if we are talking about the broader web it would be a disaster.


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