Re: PROPOSAL: Integrate ARIA attributes into the XHTML namespace

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 -------

Received on Sunday, 27 April 2008 16:20:41 UTC