Re: ARIA Proposal

On Mon, 01 Oct 2007 12:27:52 +0200, Matthew Raymond  
<> wrote:
>    So I must ask again: What it the specific problem that |role| is the
> sole solution to? Is there even a problem for which it is the /optimal/
> solution? I'm just not seeing the benefit.

It's part of the hopefully short-term, stop-gap measure, that provides  
"afterthought" accessibility for widgets created using JavaScript, HTML  
and CSS. Given that role= is already deployed, it's unlikely we need that  
name in the future, and all other attributes that are part of this are  
scoped using the aria prefix I don't think there's much harm.

The only theoretical harm I suppose is that role= is also being defined by  
the XHTML role module which defines its scope to be much greater than what  
is being implemented and what is being considered necessary by the  
stakeholders implementing. In effect, role= is more or less being forked  
to do its specific accessibility related task. Given that everything under  
discussion is still in draft form I don't see much problems here.

Introducing aria-role besides role just increases the number of options  
people have to implement unless existing content authors can be convinced  
to use the new idea instead. If that can be arranged on a relatively short  
time frime Opera might be able to change its implementation before Opera  
9.5 final. It has been suggested that this might be possible for Firefox 3  
as well.

I believe the requirements of the proposal we're talking about are:

  1. The ability to specify a widget type.
  2. The ability to specify a fallback widget type in case the
     widget type is not supported.
  3. The ability to specify widget properties.
  4. The ability to do this consistently for both HTML and XHTML
  5. The ability to also do this for other XML markup (SVG, etc.).

Of these 1, 3, 4 and 5 are addressed by Simon's proposal for ARIA. I would suggest we  
address 2 by making role= an _ordered_ space-separated list of values  
where the first value is used or, if it's not supported, the second, etc.  
If none is supported the element has no widget type. This would enable  
things like:

   <div role="aol-buddylist list">

(This fallback proposal is from Henri Sivonen if I remember correctly.)

I'm using the CSS extension mechanism syntax above as qnames have serious  
and only AT vendors will be able to introduce extensions that actually  
matter to the end user. (Maybe in that light using the prefix aol is a bad  
example, but hopefully everyone gets the idea.)

Anne van Kesteren

Received on Monday, 1 October 2007 11:11:35 UTC