Re: Next steps for the ARIA syntax discussion

Dear TAG,

On Wed, 14 May 2008 18:22:26 +0200, Williams, Stuart (HP Labs, Bristol)  
<skw@hp.com> wrote:
>   3) The TAG's working hypothesis is that "aria:" is both technically
>      feasible and strategically preferable, ...

aria:* creates an inconsistency between HTML and XHTML that we don't have  
with aria-*:

1) For HTML we would need to introduce a number of "aria:*" attributes in  
the null namespace and for XHTML and SVG we would need to introduce a  
number of "*" attributes in the ARIA namespace.

2) For styling authors would need to use [aria\:*] in HTML and @namespace  
x "ARIA namespace"; [x|*] in XHTML and SVG

3) For scripting authors would need to use getAttribute("aria:*") /  
setAttribute("aria:*", ...) in HTML and getAttributeNS("ARIA namespace",  
"*") / setAttributeNS("ARIA namespace", "*", ...) in XHTML and SVG.

The cost here is not on implementors, but authors. The design the TAG  
advocates will make transitioning towards XML even more complicated than  
it already is. In the HTML WG we drafted a design principle called "DOM  
Consistency" which is basically guiding us in ensuring that the above does  
not happen.


I think http://www.w3.org/QA/2008/05/syntax_for_aria_costbenefit_an.html  
is very misleading and misrepresenting this cost to authors:

1) It simply says to use [aria|*] for CSS in the XML case but that would  
not actually work. It also requires an @namespace at rule.

2) In a similar way it suggests that you can simply use aria:* in XML but  
that would also not actually work. It would give you a namespace  
well-formedness violation as you have not declared xmlns:aria somewhere in  
scope.

3) It says getAttribute() will function properly in the XML case but that  
would only work if the author of the page had an agreement with the script  
author about what prefix will be used which is something you should not  
rely upon. It does not mention setting the attribute which is something  
that's very important for ARIA (the whole idea is that dynamic changes are  
exposed to AT).

4) It has a column "XHTML (as if HTML)" which is something that only  
exists in some legacy specification theory and is not actually implemented  
as such by the four leading browser vendors.

5) It has the implicit suggestion there will be a million more  
vocabularies that browsers will have to add support for in similar fashion  
as they have to support HTML, SVG, MathML, and ARIA. Given the Web's  
history so far it seems unwise to add so much complexity for something  
that might happen. Once it does happen, we can then look at the  
requirements and see how to solve it. Just like we do with ARIA now.

6) It suggests that SVG would not have to be changed if used the magic of  
namespaces. That seems higly unlikely because even then you will have to  
define the interaction with the semantics of various SVG elements. In  
addition, adding complexity to the SVG specification and schemas is  
acceptable if it reduces complexity for authors. In the HTML WG we call  
this "Priority of Constituencies".


I think my conclusion is obvious.

Kind regards,


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Thursday, 15 May 2008 12:57:35 UTC