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

On Apr 3, 2014, at 1:57 PM, Joanmarie Diggs <jdiggs@igalia.com> wrote:

>> The tokenized role approach is already available in ARIA 1.0. In other words, you can do role="button link" and the computed role will be button. If and when the video roles is standardized, authors will be able to use role="video group" the way you've described.
> 
> I understand that it will work, but here's what I'm asking you to
> consider: <div role="video group" aria-roledescription="video"> as
> something allowable *today*.
> 
> Now I realize that we do NOT want to allow or encourage web devs to be
> able to put anything they feel like as the first role.

It's technically valid in ARIA for *authors* to do this already. The first role will just be unrecognized and therefore ignored and harmless. However, in response to the second half of your question. It is not conforming for a *user agent* to map an *unprefixed* non-ARIA role to a platform accessibility API. It's problematic to do this because you get into situations where UA vendors implement separate solutions to the same problem and web authors start relying on behavior of one or the other. It then becomes very tricky to undo the common usage or correct any problems. The late 1990s and early 2000s were widely considered the dark ages of web development due to this practice of "implement and ship first, standardize later."

Thankfully most browser vendors now try to reasonably specify and standardize any new Web API prior to or at the time of implementation. The standard way to propose new attributes or CSS properties has been to include a vendor-prefixed version (e.g. -webkit-border-radius) but even that is falling out of practice when there are a better alternatives. 

The ARIA team has previously discussed the potential for technology-specific prefixes (role="epub-chapter region" or role="epub:chapter region") so perhaps we could include a host language prefix in that discussion (role="html-video group" or role="html:video group"). Given the W3C's past forays into namespaced or namespace-like features, I would not be at all surprised if this is controversial or difficult to implement. 

> But if it is restricted somehow, perhaps to:
> 
> * Things we are pretty certain will be roles, and
> * Things which are already part of the host language
> 
> Then we could handle some of these cases for ATK now, and do so without
> breaking anything for the other platforms. And if web developers did
> that in their apps now, it would continue to work when it is a valid
> ARIA role.
> 
> If allowing the above *now* is not acceptable because video is not a
> valid role yet,

It's not acceptable now. Occasionally something slips in but that's usually either a mistake or something we want to correct. For example, the ARIA 1.1 "text" role has been in WebKit for at least two years. It was unspecified at the time, and if I had noticed it going in, I would have objected or pushed for the engineer to use a prefixed version such as: -webkit-text. It doesn't matter now though, because the Working Group has consensus on including that role in ARIA 1.1 (ISSUE-435).

> the only other idea I have is to provide some way to
> specify as an attribute what the equivalent element tag would be.


I think that's effectively what the epub- or html-prefixed role values would be, should we decide to go that direction.

James

Received on Thursday, 3 April 2014 21:43:11 UTC