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

On Apr 1, 2014, at 8:44 AM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:

> James Craig <jcraig@apple.com> wrote on 03/31/2014 06:18:33 PM:
> 
>>> 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".

Reflected attributes may solve this. The cases where page weight cause a significant "over the wire" lag are usually generated, so I'd err on the side of clarity rather than brevity. I'm also not convinced usage of this attribute will be so common that it will significantly weigh down a page in a legitimate use case; the cases where this is used hundreds or thousands of times in a single render tree sound like author overuse to me. If that amount is legitimately needed, it should be scripted, not sent over the wire.

> This is also part of the reason we went from presentation to none.

The main reason was clarity, not byte size.

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

Interesting. It may be difficult to ensure that the computed role is group or region without explicitly stating it, but this would allow usage on <section> without an explicitly defined role attribute.

>> What if instead we make the suggestion much less restrictive, and 
>> explain the reasons in prose.
> 
> We discussed this and Joanie, and me, both had issues with not being able to search based on type

Why can't you search based on type? The role is still the defined role. The only change would be what the screen reader user hears.

> 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

I don't know what you mean by a "limited set of applications"… Web technologies are limited to a subset of what can be done in native applications, so anything you can do on the Web, you can do natively.

> but if we are talking about the broader web it would be a disaster. 

We can't babysit web authors. At some point we have to give them the tools they need to make web apps and other web content accessible. The reality of the Web today is that no one can make web apps as accessible as native apps, because some features (including this one) are not available on the Web. 

It's good to try to prevent inexperienced web authors from misusing API, but that effort should not prevent experienced web authors from having access to that API.

James

Received on Tuesday, 1 April 2014 18:42:41 UTC