- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Sun, 27 Apr 2008 16:28:05 +0100
- To: Shane McCarron <shane@aptest.com>
- Cc: w3c-html-wg@w3.org, w3c-wai-pf@w3.org, wai-xtech@w3.org
aloha, shane! thank you for grabbing the bull by the horns, and for making a cogent, concise case for ARIA inclusion in XHTML Role -- something which i and others involved in PF have long viewed as the "best possible solution, given that we inhabit a less than perfect world"... as for your specific proposals: SM P1. Eliminate the private "aria" namespace. GJR: strong plus 1 SM P2. Incorporate the 'aria-*' attributes into the XHTML namespace. GJR: plus 1 (would be stronger if 'aria_*' but i can live with the hyphen <wink> SM P3. Define the attributes in an XHTML M12N-conforming module so that they can be easily incorporated into XHTML Family markup languages. GJR: strong plus 1 (and an offer to assist on the necessary work) SM P4. Make that module "chameleon", just like XHTML Role, so that other languages can easily incorporate the attributes into their own namespace if they choose. GJR: strong plus 1 SM P5. Ensure that such a definition does not preclude the use in non-XML grammars such as HTML 5. GJR: strong plus 1, although the issue of HTML5 integration should not, and must not be a constraint upon ARIA; it is my oft-stated belief that the issue of ARIA integration into HTML5 as framed by the HTML WG is a giant red herring -- PF asked the HTML WG to accomodate native accessibility features that correspond with the ARIA-Roadmap Table 1 [1] as a PREFERRED solution, but recognized that there will be a need for ARIA support until HTML5 becomes stable and during the transition to HTML5, both for immediate accessibility/usability and for the success of such repair strategies as those which can be provided by AccessMonkey [2]; the onus is SQUARELY on the shoulders of the HTML WG to accomodate ARIA in HTML5, not PF to modify aria to suit the self-proclaimed needs of a small sub-set of the entire HTML WG, NOR should PF endorse multiple deployment methodologies i find all of shane's rationales VERY convincing, especially: <quote cite="http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/0382.html"> 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. </quote> SM R3. 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. GJR: this itself is a VERY compelling argument for including ARIA in XHTML Role; SM R4. There will only be one "name" for all the ARIA attributes. GJR: ah the clincher -- THAT is a consummation devoutly to be wished on a closing note, as a member of the PF, HTML and XHTML2 working groups, i am quite dismayed by the continued vociferousness of the "us versus them" mentality of some of the most vocal proponents of HTML5 -- HTML serves a different, far more limited, purpose than XHTML; otherwise, why would HTML be seeking a serialization as "XHTML5" (which itself is a fallacious name, but that is a subject for another thread) we are NOT tasked with deciding an either/or proposition, but, rather, a technology that is aimed at improving functionalities and plugging enormous holes in accessibility, NO MATTER WHAT THE MARKUP LANGUAGE... gregory. [1] http://www.w3.org/TR/wai-aria-roadmap/#desktop_fill -------------------------------------------------------------- DISCUSSION, n. A method of confirming others in their errors. -- Ambrose Bierce, The Devil's Dictionary -------------------------------------------------------------- Gregory J. Rosmaita, oedipus@hicom.net Camera Obscura: http://www.hicom.net/~oedipus/ -------------------------------------------------------------- ---------- Original Message ----------- From: Shane McCarron <shane@aptest.com> To: HTML WG <w3c-html-wg@w3.org>, w3c-wai-pf@w3.org Sent: Fri, 25 Apr 2008 11:17:15 -0500 Subject: PROPOSAL: Integrate ARIA attributes into the XHTML namespace > 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 ------- End of Original Message -------
Received on Sunday, 27 April 2008 15:29:59 UTC