- From: T.V Raman <raman@google.com>
- Date: Thu, 11 Oct 2007 10:30:57 -0700
- To: annevk@opera.com
- Cc: schwer@us.ibm.com, public-html@w3.org, wai-xtech@w3.org
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:50 UTC