RE: Next steps for the ARIA syntax discussion

Hi Anna

I am losing your thread here - Might be missing the obvious but is there  a
fundamental problem in defining the xmlns:aria somewhere in scope? 

Best 

Lisa
 

-----Original Message-----
From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On Behalf
Of Anne van Kesteren
Sent: Thursday, May 15, 2008 3:57 PM
To: www-tag@w3.org; public-html@w3.org; public-xhtml2@w3.org;
wai-xtech@w3.org
Subject: 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 13:58:44 UTC