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

Received on Sunday, 27 April 2008 16:07:35 UTC