Re: State and Status of WAI-ARIA approach to host-language embedding

On Thu, 17 Apr 2008 15:33:57 +0200, Henry S. Thompson <ht@inf.ed.ac.uk>
wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Cooper writes:
>
>> . . . I have prepared a summary document [0]
>
> I too have found this very helpful, thank you.
>
> I have spent some time exploring the test case helpfully provided by
> Henri Sivonen [1].  I discovered that at least some of the apparent
> failures of the :-based markup versions therein did not arise from the
> material under test, but from accidental properties of the text
> matrix.

It's not really clear to me what it is that you discovered. It seems to me  
that you have tried to work around the differences that the colon imposes  
and thus demonstrated that different code paths is needed.


> More generally, it appeared to me that if a bit more effort were
> expended, the cost of the :-based approach could be reduced, thus
> perhaps shifting the outcome of what we all agree is a cost-benefit
> tradeoff.
>
> Accordingly I produced a new version [2] of Henri's test, testing only
> my more elaborate :-based approach, which produces better results
> (live version [3]) (frozen snapshot w. low-res thumbnails if the live
> version has expired [4]).

Using the colon means that UAs and authors have to support two sets of  
ARIA attributes -- one set of namespaced attributes, and one set of  
no-namespace attributes with colons in their local names. Having aliases  
is an indicator of bad design. Moreover, it will be seriously error prone
for authors, since attributes from either set can appear on the same node  
in both HTML and XML documents:

Case 1: HTML document:

    <div a:foo='true'>

    div.setAttributeNS('http://www.w3.org/2005/07/aaa', 'foo', 'false');

Case 2: XHTML document:

    <div a:foo='true'>

    div.setAttribute('a:foo', 'false');

Case 3: either HTML or XHTML document:

    <div>

    div.setAttributeNS('http://www.w3.org/2005/07/aaa', 'foo', 'true');
    div.setAttribute('a:foo', 'false');


> The crucial observation about these results
> is that in every case Javascript access to :-based ARIA attributes
> succeeded, and in all but the Safari case (which I presume could be
> fixed, I just couldn't get access to a Safari + debugger installation
> in the time available) the Javascript setting of :-based ARIA
> attributes succeeded.

It fails in Safari because your "XML" check is actually bogus:

    if  ( document.xmlVersion || document.documentElement.namespaceURI ) {
      getARIAttr = function(elt,name) {
        return elt.getAttributeNS('http://www.w3.org/2005/07/aaa',name);
      }
      setARIAttr = function(elt,name,val) {
        elt.setAttributeNS('http://www.w3.org/2005/07/aaa',name,val);
      }
    }
    else {
      setARIAttr = function(elt,name,val) {
        elt.setAttribute('a:'+name,val);
      }
      getARIAttr = function(elt,name) {
        return elt.getAttribute('a:'+name);
      }
    }

Per HTML 5, elements that are inserted in the document by the HTML parser  
are put in the XHTML namespace, and hence, you get the "XML" codepath for  
HTML documents in UAs that follow HTML 5.

Also see:  
http://lists.w3.org/Archives/Member/w3c-wai-pf/2007OctDec/0275.html  
(please ignore my setAttributeNS copy-paste error).

No matter how you try to spin it, even if you get the "XML" check right, a  
node can have both attributes set at the same time, and there's no way to  
tell which one was the last updated one, so you don't know the actual  
intended state. The right way to solve this is to only have one set of  
attributes, and that means not using the colon (given the constraints that  
we can't change the HTML parser, nor the XML parser, nor DOM Core, and  
that it should work the same in existing browsers).

     setARIAttr = function(elt,name,val) {
       elt.setAttribute('aria-'+name,val);
     }
     getARIAttr = function(elt,name) {
       return elt.getAttribute('aria-'+name);
     }

(Althought it's probably equally convenient to just use setAttribute and  
getAttribute directly, which authors are already familiar with, than  
having the above indirection just for ARIA.)


> CSS selection succeeded everywhere except IE,
> where it failed across the board -- I presume this could be fixed for
> IE8, given what I understand, but again I didn't have access to a
> suitable IE8 installation.

     p[a\:foo], p[a|foo] { background:lime }

IE doesn't support namespaces in CSS, and so, the entire ruleset is  
dropped. However, even if you did:

     p[a\:foo] { background:lime }
     p[a|foo] { background:lime }

...IE7 wouldn't apply the first ruleset because attribute selectors with  
colons don't work in IE7. (Attribute selectors without colon work fine in  
IE7.) But, even if attribute selectors with colon did work in IE7, you'd  
still have to duplicate all your ARIA rulesets in CSS, and that's bad  
compared to not having to do so:

     p[aria-foo] { background:lime }


> I think this outcome, based on 6 hours' work by someone who is
> definitely _not_ a Javascript/DOM/Browser-implementation wizard, calls
> into question a crucial assertion in the argument (from [0]) against
> the :-based solution:
>
>   "Script authors would have to write alternative code for different
>   browsers in their scripts for manipulating our state-variable
>   attributes if they have names with colons.  This is a large extra
>   burden on the script authors and hence [a] significant barrier to
>   uptake of the accessible markup style."

I think you have successfully demonstrated the exact problem with the  
colon. Most authors are not Javascript/DOM/Browser-implementation wizards,  
and have perhaps never used namespaced CSS or NS methods in the DOM, and  
so would run into the same problems you did (grouping selectors instead of  
duplicating ruleset; not realising that elements in HTML documents can be  
namespaced; not realising that elements can have both attributes at the  
same time).


> The necessary Javascript to enable simple uniform access to and
> setting of ARIA attributes across browsers and indifferently wrt XHTML
> vs HTML in [2] is 16 lines long.  Including and using this code in
> scripts designed to exploit ARIA is likely to be a _very_ small
> overhead, certainly not a "large burden", compared to the ARIA
> applications themselves, and in my view is a cost people should and
> will be happy to pay to avoid the confusion for authors which will
> arise as they try to understand when to use aria: and when to use
> aria- if we follow the currently-favoured path.

I think we can't come to useful conclusions from your script since it  
doesn't work correctly in UAs that implement HTML 5, nor does it cover the  
case when an element has both attributes at the same time. However, even  
ignoring that, 16 lines of code and the resulting indirection elsewhere in  
the code is bad compared to no additional 16 lines of code and no  
indirection elsewhere in the code.


> [0] http://www.w3.org/2008/03/aria-implementation
> [1] http://simon.html5.org/test/aria/colon-vs-dash/
> [2] http://www.w3.org/XML/2008/04/colon-test.html
> [3] http://browsershots.org/http://www.w3.org/XML/2008/04/colon-test.html
> [4] http://www.w3.org/XML/2008/04/colon-test-results.html

-- 
Simon Pieters
Opera Software

Received on Thursday, 17 April 2008 15:39:42 UTC