Re: ARIA Proposal

Hi Anne,

Simon's proposal does not mention stating the set of roles as a fallback
mechanism sequence. That needs to be handled elsewhere. I am also worried
that having multiple roles as you stated (for fallbacks) will make things
more complicated for authors.

Back to the forking issue:

You know that the role module does not actually say what the user agent
should do with the role attribute. Even if it were a qname you could just
treat the role as a string and pass it off to the AT. So, from an AT
interoperability piece it really is a situation where we say treat it as a
string:

flowchart:decision

for example.

If middelware wants to use the role qname for some other purpose should the
browser really care?  For example, Mark Birbeck uses roles to do semantic
processing of the document. That does not impact the browser.

At one point a document was created in the W3C to state how the browsers
support HTML DOM. As HTML 5 progresses we do the same thing here. For now
if it is not one of the standard aria or xhtml roles (no namespace required
per the proposal) we treat it as a string or we can follow the fallback
mechanism below.

So, are we making too much of this?

Rich


Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review  Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer


                                                                           
             "Anne van                                                     
             Kesteren"                                                     
             <annevk@opera.com                                          To 
             >                         "Matthew Raymond"                   
             Sent by:                  <mattraymond@earthlink.net>,        
             wai-xtech-request         public-html@w3.org                  
             @w3.org                                                    cc 
                                       wai-xtech@w3.org                    
                                                                  Subject> 
             10/01/2007 06:11          Re: ARIA Proposal                   
             AM                                                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





On Mon, 01 Oct 2007 12:27:52 +0200, Matthew Raymond
<mattraymond@earthlink.net> 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
http://simon.html5.org/specs/aria-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
issues http://lists.w3.org/Archives/Public/public-html/2007Sep/0520.html
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
<http://annevankesteren.nl/>
<http://www.opera.com/>