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

My understanding is that <div role="region" roledescription="chapter" .... 
would still expose the role of the div to the AT as region. None of the 
role information is lost. Presumably in this case, an e-pub reader would 
reveal navigation commands to users based on the roledescription, e.g., a 
"Next Chapter" button with a keyboard shortcut and/or its own gesture.

If an element is not interactive, then changing the name of the role 
revealed to an AT user could make content more understandable without 
risking any deterioration in operability. The possible improvements in 
understandability with this feature could be substantial. Making up for 
the ambiguity of generic roles like region or group with labels creates 
messy, hard to understand experiences. In fact, as an end user, I almost 
detest roles like region and group just for this reason. 

Here is an example of why group can be so detestable. Say you have an 
editor and you want to indicate this run of text, " His words saved the 
day! ",  is an insertion by Joe. So, you give it role group with label 
"Insertion by Joe"  Then a screen reader may announce role, label, and 
value as:
"group insertion by Joe His words saved the day!"
In a context like this, the word "group" is extremely deleterious to 
understanding and quality of user experience. Imagine many of these 
embedded in paragraphs of text the user is attempting to comprehend.

If instead, the group had roledescription of "Insertion" and label "by 
Joe" then we could have:
"Insertion by Joe His words saved the day!"

Admittedly, this is still not ideal because a good AT that knows text is 
an insertion element would treat it in a much more intelligent manner. 
Nonetheless, this is a simple example of how generic container names just 
clutter and degrade understanding and experience.

That said, I do agree with James's assertion that limiting to just region 
or group could lead to misuse; developers will always try to expand boxes 
that feel too small. We discussed waiting for 2.0 to extend this feature 
to widgets. But, we should at least have the conversation of what that 
extension would look like now. Perhaps it is containable.

Some practical use cases for use on widgets would be helpful to the 
discussion.

Since the semantic role would still be revealed to the AT for an 
interactive element, the AT could base any user hints or tutor information 
about operation on the role but speak or reveal the role of the element 
using the roledescription.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   "lisa.seeman" <lisa.seeman@zoho.com>
To:     Shane McCarron <shane@aptest.com>, 
Cc:     "Steve Faulkner" <faulkner.steve@gmail.com>, James Craig 
<jcraig@apple.com>, Richard Schwerdtfeger/Austin/IBM@IBMUS, "W3C WAI 
Protocols & Formats" <public-pfwg@w3.org>
Date:   04/01/2014 03:53 AM
Subject:        Re: ISSUE-636 CTION-1398 Provide spec. text for 
aria-roledescription



My two cents is that you can make a group and add a label. I am not sure 
exactly what having an extra string will help.

I suggest that we make it a URI to an RDF type that uses  the aria role 
OWL ontology, where each type must include  a description but also machine 
determinable relationships to existing roles.

That way the roles are actually machine understandable. However, ovelaps 
can be identified, and author freedom is maintain.

If we decide to go that direction I could set up a simple template so that 
people who do not speak RDF can add a role extension and roledesc , we can 
enable reuse   and we can track/ warn about duplication.

All the best

Lisa Seeman

Athena ICT Accessibility Projects 
LinkedIn, Twitter




---- On Tue, 01 Apr 2014 04:39:17 +0300 Shane McCarron<shane@aptest.com> 
wrote ---- 

Steve,   I disagree.  The whole point of having vocabulary spaces is to 
avoid the need for registration.  Within a vocabulary space, the 
maintainer(s) can manage their own collection of terms.  We don't need to 
be gatekeepers here.  In particular since the values for the attribute 
don't have any semantic meaning to an AT.


On Mon, Mar 31, 2014 at 8:28 PM, Steve Faulkner <faulkner.steve@gmail.com> 
wrote:
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


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