Re: ARIA Proposal

Note that the intent of multiple roles in the original draft I
wrote in 2003 was exactly modeled on CSS font rules.

Basically you want multiple role values for the case
role="my-fancy-dancing-button button"
--- so that you at least  get the access support for a button
even if your AT doesn't know what my-fancy-dancing-button is.

Anne van Kesteren writes:
 > 
 > On Wed, 10 Oct 2007 16:04:39 +0200, Richard Schwerdtfeger  
 > <schwer@us.ibm.com> wrote:
 > > 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.
 > 
 > It does deal with it though. I don't think it makes things more  
 > complicated for authors. They are already familiar with this concept as it  
 > is very similar to how CSS works, for instance:
 > 
 >    font-family:Arial, sans-serif;
 > 
 > It is also way simpler than what the PFWG has introduced for fallback.  
 > Namely using RDF at the end of a role URI to indicate what the fallback  
 > role is. (Which the UA has to fetch, etc.) If having a fallback scenario  
 > is indeed a requirement this seems like the simplest solution to solve it.
 > 
 > 
 > > 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.
 > 
 > That seems totally wrong as foobar:decision and flowchart:decision can  
 > totally mean the same thing per the definition of role (in so far there is  
 > one).
 > 
 > 
 > > 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.
 > 
 > As I explained and illustrated with an example above it would impact the  
 > browser. It also makes things confusing for authors as the document  
 > conformance criteria would probably have to cover all those cases. It  
 > seems unwise to overload role in this way.
 > 
 > 
 > > 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?
 > 
 > I'm not sure what you're trying to say here.
 > 
 > 
 > -- 
 > Anne van Kesteren
 > <http://annevankesteren.nl/>
 > <http://www.opera.com/>

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Thursday, 11 October 2007 17:31:49 UTC