W3C home > Mailing lists > Public > public-xhtml2@w3.org > April 2008

Re: PROPOSAL: Integrate ARIA attributes into the XHTML namespace

From: Shane McCarron <shane@aptest.com>
Date: Mon, 28 Apr 2008 11:00:41 -0500
Message-ID: <4815F4A9.8080703@aptest.com>
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:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 February 2010 18:12:48 GMT