The ARIA debate (held Tuesday morning) during the W3CTP 2007 shifted away from role at the start almost exlusively discussing what syntax to use for the ARIA properties. My recollection is that these were the proposals:
aria-property-name
aria_property-name
aria:property-name with aria bound to the ARIA namespace
My recollection of the requirements is as follows:
text/html serialization of HTML consistently accross existing implementations. Specifically, DOM operations for adding and removing attributes should be identical and you should be able to style elements using CSS based on the attribute and its value.
How those, combined with the fact that we want them to look like they are part of the language, does not automatically lead to aria-property-name is something called W3C politics and imagine a lovely subject for academics to study. Henri Sivonen has been explaining these arguments elaborately four times (two teleconferences, e-mail, and face-to-face) and still the opposition comes with arguments like “namespaces are the W3C’s answer to extensibility” which seems to miss the point as we’re trying to make the low-level accessibility API, that ARIA is, part of HTML.
Then there is another discussion regarding the role attribute. That attribute seems politically loaded (also overloaded, which has historically led to bad interoperability) and I think we would be better off if we simply named the thingie we need for ARIA aria. This has the additional benefit of nicely implying how the ARIA properties are related.
So let HTML have:
and XHTML and SVG have:
That would make the HTML folks (and existing colon-shy implementations) happy and it would make the XML folks (myself included) reasonably happy.
In a sense, for the HTML case, the HTML's "namespace" subsumes the aria "namespace"
I would prefer if the serializations were the same in HTML5 and XHTML5. That being said, I don't have a strong preference between the three characters chosen: none of the three are "valid" in HTML4 (where valid means "defined by the DTD"), and all three could "work" in XHTML5.
I do, however, strongly believe that there needs to be a mechanism by which long tail requirements for markup additions can be accommodated without requiring the attention of either the full W3C, or even the full WHATWG.
[...] I think we would be better off if we simply named the thingie we need for ARIA "aria".
I was pushing the name "aria-role" for the attribute name, but "aria" is just as good. Perhaps even better, since it leaves the term "role" out entirely.
Sam, I understand your point now about serializations being the same between HTML5 and XHTML5. So I guess now I fully understand why we're at this impasse. By the way, since namespace declarations are required in XHTML5 I guess it's ok for the root <html> element to have some xmlns and xmlns:svg attributes on it?
I know this would be a change to the whole XML namespace concept, but C++ has this concept of "using" a namespace (i.e. putting everything in that namespace into the global/default namespace). It's not a recommended approach because of collisions, but it could simplify things for newcomers and provide the same serialization that you want.
A XML equivalent to the whole "using namespace" concept from C++ might be:
<?xml version="1.0"?>
<svg xmlns="..." xmlns:xlink="..." xmlns:aria="..." xml:usingNamespaces="xlink aria" >
<a href="example.com" aria-checked="true" ><circle fill="red" > </a>
</svg>
Of course the above would require a spec to drive the whole "usingNamespaces" idea and I don't know what other problems this might cause.
Continuing my fantasy, without the usingNamespaces attribute on the root element, the code would have to be:
<?xml version="1.0"?>
<svg xmlns="..." xmlns:xlink="..." xmlns:aria="..." >
<a xlink:href="example.com" aria:aria-checked="true" ><circle fill="red" > </a>
</svg>
Thinking along the C++ lines some more, we'd want the XML parser/processor to spit up an error if there is an element or attribute collision (for instance if you included the XHTML namespace inside the SVG namespace, I'd expect any usage of the <a> element to cause a problem and force the user to use a prefix to disambiguate (or, if we want to be forgiving, the element that is in the current namespace before the inclusion could be used).
Jeff, your proposals are not in line with the requirements.
Anne, as I was concocting this fantasy, I guess I realized that it could never happen anyway: There is simply too much infrastructure in place for XML as it is today for such a change to be allowed
What change? I think you’re either missing the point or I’m misunderstanding you.
The change = "Letting an XML document promote elements and attributes of an XML namespace to the default namespace".
It is totally tangential to the ARIA discussion and only entered into the picture when I tried to imagine a way for the ARIA attributes to still be in their own namespace, but to have a common representation of those elements in HTML5, XHTML5 and SVG. See my comment.
It is also impractical and fraught with problems. Moving on... :)
I must have missed the point along the way, but what is the benefit of using ARIA in the first place ?
Peter, the purported benefit of aria is that it allows additional semantics to be applied to elements, specifically targeted at assistive technology.
In theory, it allows authors to create custom controls by misusing HTML elements like, for example, span and div with scripts and styles applied and then expose that functionality to assistive technology using ARIA so that such users can still interact with the control in a reasonable way. In practice, it's far too complicated for most authors to even think about using. It's proponents are primarily relying on its adoption into JavaScript frameworks that insert it automatically for it to even be remotely successful.
Personally, I remain opposed to the adoption of aria and don't have much faith in its overall success. However, since the whole thing is a mess right now, mostly because of the complexities of namespaces, it is unfortunately better to include a cleaned up version of it in HTML5 that is designed for use in the HTML serialisation, while at the same time sorting out and defining how to handle the namespace mess. At least that will give it some chance of interoperability for the few authors that will use it.