W3C home > Mailing lists > Public > wai-xtech@w3.org > April 2008

PROPOSAL: Integrate ARIA attributes into the XHTML namespace

From: Shane McCarron <shane@aptest.com>
Date: Fri, 25 Apr 2008 13:45:15 -0500
Message-ID: <481226BB.1000108@aptest.com>
To: HTML WG <w3c-html-wg@w3.org>, "'wai-xtech'" <wai-xtech@w3.org>

(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
Received on Friday, 25 April 2008 18:45:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:35 UTC