The issue of 'aria:' vs. 'aria-' has in part turned on evidence of the behaviour of deployed browsers. I have spent some time exploring the test case helpfully provided by Henri Sivonen and the tests provided by the Illinois Center for Information Technology Accessibility (iCITA). I discovered that at least some of the apparent failures of the :-based markup versions of Henri's tests did not arise from the material under test, but from accidental properties of the text matrix. I also found that the iCITA examples, although labelled in some cases as XHTML, were in fact not being treated as XHTML by e.g. Firefox.
Accordingly, I've prepared new tests comparable to Henri's, and experimented with a true XHTML version of one of the iCITA examples.
The first experiment used a a new test document similar to Henri's, but with the bugs fixed and some additional Javascript added. Using the facility kindly provided by Browsershots, I explored the results across a wide range of browsers.
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. CSS selection succeeded everywhere except IE, where it failed across the board -- I presume this could be fixed for IE8, if Microsoft chooses to do so.
See a www-tag thread for discussion of these results.
The first experiment was criticised in part for requiring that Javascript access
to ARIA properties be mediated via getter and setter functions. The second
experiment used the same document markup as Experiment 1, but differeent
Javascript: it explored the consequences of using only
GetAttribute("aria:...") and
SetAttribute("aria:...",...), as well as improving the styling of the
results to make them easier to read.
The only difference in outcome was that Opera now fails the attribute access
test when processing a document as XML. This appears to be because, contrary to e.g. the definition of GetAttributeNode in the DOM specification,
it matches the argument to GetAttribute against the local
name, rather than the nodeName, of the attribute nodes it checks.
Another frequently-voiced concern in discussions of ARIA syntax is that significant implementation effort has already been expended based on the aria- approach, and a change to a :-based approach would waste this effort and risk alienating implementors.
The third experiment attempted to address this in the following way: I
installed Firefox 3 beta 5 from source, added the Firefox accessibility extensions
and installed Orca accessibility for Gnome on my Fedora Core 6 Linux machine.
After fixing some small bugs in the Javascript associated with the iCITA test I was
using (Checkbox
1) so that it would work whether presented as text/html or
application/xhtml+xml, I explored the difficulty of changing Firefox's
ARIA support from being based on aria- to being :-based. Because the code was
well-structured, although I am far from understanding all the details,
I found that simply replacing all occurences of aria- with
aria: achieved screenreader performance with a
:-based version of the iCITA test which was nearly identical to performance using
an unmodified browser and the original (based on aria-) iCITA test.
It took me about half a day to achieve this, once I had succeeded in getting Firefox 3 to build and install. I am confident that virtually all the implementation investment made so far in implementing ARIA based on an aria- syntax would carry over to a :-based approach, because it's clear even from my brief experience that the vast majority of the code involved is managing the architecture of the interaction between ARIA and ATK, not the syntax.