- From: Shane McCarron <shane@aptest.com>
- Date: Mon, 28 Apr 2008 11:00:41 -0500
- To: "Gregory J. Rosmaita" <oedipus@hicom.net>
- CC: XHTML WG <public-xhtml2@w3.org>, w3c-wai-pf@w3.org, wai-xtech@w3.org
Thanks for the clarification. Also note that I have changed the cc list - I had accidentally cc'd the old member only html wg list in my original posting. Gregory J. Rosmaita wrote: > aloha, shane! > > agreed -- i wasn't advocating that ARIA be made part of XHTML Role, > but that it should be in the xhtml namespace precisely because it > makes integration with XHTML languages seamless, eases the burden > on the author, and makes it quite straightforward to combine with > XHTML Role... > > just as Role has greater applicability than WAI-ARIA, WAI-ARIA has > broader applicability: in particular, to general markup languages, > such as HTML, as opposed to extensible and/or specialized markup > languages, as well as making "web 2.0" widgets accessible NOW... > > render unto Role what is properly Role's, and render unto WAI-ARIA > what is properly in the purview of WAI-ARIA, but by all means, the > twain should occupy the same namespace... > > apologies for the ambiguity of my previous post -- i should have > re-re-re-re-re-read it before sending it, especially after sleeping > on it, > > gregory. > ---------------------------------------------------------------- > CONSERVATIVE, n. A statesman who is enamored of existing evils, > as distinguished from the Liberal, who wishes to replace them > with others. -- Ambrose Bierce, _The Devil's Dictionary_ > ---------------------------------------------------------------- > Gregory J. Rosmaita, oedipus@hicom.net > Camera Obscura: http://www.hicom.net/~oedipus/index.html > ---------------------------------------------------------------- > > ---------- Original Message ----------- > From: Shane McCarron <shane@aptest.com> > To: "Gregory J. Rosmaita" <oedipus@hicom.net> > Cc: w3c-html-wg@w3.org, w3c-wai-pf@w3.org, wai-xtech@w3.org > Sent: Sun, 27 Apr 2008 11:06:58 -0500 > Subject: Re: PROPOSAL: Integrate ARIA attributes into the XHTML namespace > > >> Thanks for your comments. Note that I am not exactly proposing >> that ARIA be made a part of XHTML Role. I don't mind that. >> What I am proposing is that it be in the XHTML namespace. That >> makes integration with XHTML languages seamless, eases authoring, >> AND makes it straightforward to combine with XHTML Role. I >> think XHTML Role has a wider applicability than just WAI-ARIA. >> That's the only reason I don't want to combine them into a >> single module. >> >> Gregory J. Rosmaita wrote: >> >>> 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 ------- >>> >>> >>> >> -- >> 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 ------- > > -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
Received on Monday, 28 April 2008 16:01:59 UTC