Re: PROPOSAL: Integrate ARIA attributes into the XHTML namespace

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