PROPOSAL: Integrate ARIA attributes into the XHTML namespace

a loud 1+ on this.

Shane McCarron writes:
 > 
 > (resent to wai-xtech so it is public)
 > 
 > XHTML 2 and PFWG members,
 > 
 > I have been following with interest the debate in the TAG regarding the
 > mechanism the PFWG has proposed for addressing issues with namespaces
 > and support for the ARIA work in non-XML user agents.  I appreciate all
 > of the effort that has gone into the debate, and of course understand
 > that there are strong opinions on all sides.  In the middle of that
 > debate, I read an impassioned plea from Rich for some sensibility, which
 > I translated as "Can't we all just get along?"
 > 
 > In the spirit of that, I tried to think outside the box a little bit -
 > just as we did at the f2f meeting in Venice when considering how to deal
 > with ARIA-defined values for @role.  Consequently, I propose the following:
 > 
 >    1. Eliminate the private "aria" namespace.
 >    2. Incorporate the 'aria-*' attributes into the XHTML namespace.
 >    3. Define the attributes in an XHTML M12N-conforming module so that
 >       they can be easily incorporated into XHTML Family markup languages.
 >    4. Make that module "chameleon", just like XHTML Role, so that other
 >       languages can easily incorporate the attributes into their own
 >       namespace if they choose.
 >    5. Ensure that such a definition does not preclude the use in non-XML
 >       grammars such as HTML 5.
 > 
 > I propose this for (at least) the following reasons:
 > 
 >    1. It costs *us* nothing (there is work for the PFWG, but it costs
 >       the XHTML 2 Working Group nothing ;-).
 >    2. It promotes the ARIA techniques in the same way that incorporating
 >       Ruby or Xforms into the XHTML namespace promoted them - helping
 >       ensure they are not viewed as second class technologies.
 >    3. It basically eliminates the problems with CSS styling and access
 >       to the attributes via JavaScript, including the ability to develop
 >       style sheets and scripts that work portably regardless of whether
 >       the enclosing document is treated as HTML or XHTML - for the vast
 >       majority of use cases, anyway.
 >    4. There will only be one "name" for all the ARIA attributes.
 > 
 > I fully understand that this is not a perfect solution.  I also expect
 > that there are people who will continue to object to using a dash for
 > scoping instead of the well-defined QName mechanism.  Those objections
 > are legitimate and there are long term ramifications to not using
 > namespaces when they are appropriate.  However, I think in this case
 > relegating these critical accessibility enablers to a non-XHTML
 > namespace serves no one, and therefore the use of an alternate namespace
 > for this work is inappropriate.  Unfortunately, attempting to
 > incorporate the attributes into the XHTML namespace and XHTML markup
 > languages without the aria- prefix would be impossible.  There would be
 > too many collisions with existing attribute names.
 > 
 > Ignoring the technical side of the debate, we have a responsibility to
 > all members of the web community - and that community includes A LOT of
 > people who are being rapidly disenfranchised because accessibility is
 > just too damn hard in the Web 2.0 world.  We need to solve this.  And
 > solve it now.  I say we embrace the ARIA solution in the XHTML space and
 > move on!
 > 
 > -- 
 > Shane P. McCarron                          Phone: +1 763 786-8160 x120
 > Managing Director                            Fax: +1 763 786-8180
 > ApTest Minnesota                            Inet: shane@aptest.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 Friday, 16 May 2008 16:23:41 UTC