ARIA is an abbreviation for which the title of this post is the expansion (among others) and is also used to refer to a solution that enables accessibility on top of existing web applications that heavily rely on scripting, et cetera. If you have made your own slider control using a set of div elements, some ECMAScript, and CSS, you can now, as afterthought, add support for screen readers. This is of course not the right way to go about things, but since <input type="range"> is not universally supported, styling scenarios for the new Web Forms 2.0 widgets are not ideal yet (waiting for XBL plus CSS appearance) and because it might take a while before authors switch to the HTML5 goodness (waiting for Internet Explorer) an adhoc solution to provide accessibility as afterthought for web applications might be worthwhile. Especially since it can be quickly deployed and, nobody says this explicitly, but believe me, this is the reason: it does not rely on Microsoft playing along.
The problem is of course that the accessibility group at the W3C that is tackling the problem is looking into solving it for XHTML. And not simply solving it, no, over engineering, yes. Solving it for XHTML solves no problem for anybody because Internet Explorer does not support XHTML. I’m not sure how you go from “needs to work on top of existing content” and “needs to work for authors targetting Internet Explorer” to “lets make heavy use of namespaces and build on top of XHTML” and yet this is exactly what happened. Henri Sivonen would add “spec lawyering” here. Their extremely clever solution resulted in AT vendors building on top of Internet Explorer to use non namespace-aware, opaque string, attribute getters which in turn requires authors to use specific strings such as aaa:disabled instead of foo:disabled with foo bound to the right namespace. Not all. In order for this to work in Firefox authors have to use ugly hacks in their text/html documents. Let me point out that if you want to provide an adhoc solution for afterthought accessibility you need to make it as simple as humanly possible for it to work in text/html. No need to go out of your way to please the namespace gods and whatnot, think of the people using and building the applications!
Time to go into a bit more detail before we involve the bright side. You can indicate that an element represents a custom widget using the role attribute. This role attribute takes a whitespace separated list of values each which represents some role defined in some draft. What’s relevant here is that in practice (Firefox plus assistive technology) only the first will be used and all other values are ignored. To be fair, nobody I talked to has a clue on what effect multiple roles would have in practice. The widget can also have a lot of other attributes in a certain namespace. We call those attributes the widget properties for the purposes of my article. You declare those like I mentioned before: aaa:widget-property="widget-property-value" with aaa bound to some namespace. You also need to update these attributes based on interaction with the widget and make the widget keyboard accessible using tabindex et cetera, but this is not really a tutorial on how to do that. It’s a rant with a bright side. (It’s a little bit more ugly than outlined so far actually, the role attribute can for example also be in the http://www.w3.org/TR/xhtml2 (indeed!) or http://www.w3.org/1999/xhtml namespace in Firefox, the whitespace separated values of role are qnames currently, et cetera. Mu.)
There is currently a proposal on the table from various content providers and browser vendors that tries to solve the aforementioned problems at least partially (Simon started drafting). There is no real consensus yet on how to deal with deployed content as it’s unclear if it can be changed or is significant enough to be worth the implementation cost (quality assurance, codebase complexity). Anyway, support the role attribute in no namespace in both HTML and XHTML. Let it take simple opaque string values. Introduce a bunch of aria-widget-property attributes for both HTML and XHTML without complicating DOM interfaces to handle the widget properties. Have this shipped in Firefox and Opera. Encourage authors to use it. Lets see how it goes.
Pseudo-supporting namespaces for attributes in IE's JavaScript is pretty trivial if you play by some small constraints, and you don't have to treat attribute names quite as opaquely as these authors are.
Your constraints are basically:
You can then parse the namespace declarations into a lookup table and use those to fudge getAttribute.
It's certainly still a hack, and IE doesn't have any understanding of the namespaces (of course), but it gives you a way to support namespaces on a browser that doesn't natively, and you can do it (if you're not stupid) without breaking XHTML-aware parsers.
Yeah, I’m aware of that. Fortunately, it is way to complicated to be considered. I hope!
I think the big problem is really that this is the sort of thing that HTML-as-an-application-of-XML was designed for, and in many ways hacking “sufficient” support for namespaces into IE via the scripting model which you can do right now, of course) is a path of significantly lesser resistance ( than either waiting for HTML 5 or coming up with a whole other solution altogether.
If all the user-agents out there supported XHTML it'd be a complete no-brainer; it is after all ideally suited (far moreso than continually adding new stuff for specific classes of applications to HTML itself) to the task.
This makes a lot of sense, Anne. I was thinking ARIA needs to work in text/html and HTML5 might be the place that would happen back in March this year. With Simon and Aaron leading the effort to spec this, it's bound to turn out great! :)