And this is Updates on the "ARIA stylesheet" hack, written Feb 25, 2009, and concerning Web

My ARIA "stylesheet" hack came up on the WAI-XTech mailing list. Some of my commenters here, and some of the people on the list, seem to have misapprehended what the proposal was designed to do; I've mailed the list, but it seems useful to post these clarifications here too.

I am not proposing adding ARIA to CSS. An "ARIA stylesheet" looks like a CSS stylesheet because that's a convenient way to apply properties to elements, but they aren't the same thing.
I'm not proposing that the technique requires JavaScript. My suggestion is that browsers natively understand how to retrieve an "ARIA stylesheet" and apply the ARIA attributes defined therein to elements, as per the selectors in the "stylesheet". The JavaScript implementation was just to demonstrate how it would work, and a prototype for how people might support older browsers which don't have this native "ARIA parsing", in the same way that there are JavaScript libraries which mimic HTML5 WebForms handling for older browsers that don't yet support <input type="range">.
The "ARIA stylesheet" only dictates the initial setup of a page, in much the same way that a CSS stylesheet does for presentation. If I use JavaScript to alter the style of an element, that change is not reflected in the CSS stylesheet text, but it is obtainable through element.style or getComputedStyle(). In the same way, altering an ARIA attribute on an element through JavaScript would work perfectly well, and the current value is obtainable through element.getAttribute("aria-role") or similar.
I understand that ARIA is semantic and therefore belongs more directly in the HTML than mere presentation does. However, distinct advantages to moving ARIA information out into a separate document do exist:
1. It allows me to "ARIAify" an entire website very easily, much as having CSS in a separate stylesheet allows me to change the design of a site very easily. At the moment, to "ARIAify" a website I have to edit every single page in great detail. If a site is already properly marked up and relatively consistent in the way it uses that markup, adding ARIA roles and attributes could be done relatively easily by adding one file, the ARIA stylesheet, and a <link rel="aria" href="..."> element to the head of each page.
2. It avoids the validation problem, that ARIA attributes will currently cause a document to fail validation
3. It reduces bandwidth required to serve a site, meaning that sites load faster and servers work faster and cheaper, in two ways:
  1. The "ARIA stylesheet" can be cached by browsers, meaning that it needs only be served once per site; embedding attributes in the markup means that every page gets larger and the attributes are not cached
  2. User agents that are not tied into native accessiblity APIs (for example, users who do not have the accessibility APIs switched on because they don't need them) do not need to fetch the ARIA stylesheet at all, saving even more bandwidth

Hope this helps clarify my thinking. Comments are welcomed.

Comments

AlastairC

I like this, and I would use it.

It seems strange to have:

<div id="navigation" role="navigation">

(Hopefully the above code comes out ok...)

You would have to be clear that it is for the initial state though, anything dynamic should probably be assigned by the script itself.

cookiecrook.com/

For certain landmark roles (like navigation, banner, main, etc.) your method is fine, though as you stated, it'd be better to have it in the DOM for all browsers, whether or not they support a native method to read ARIA information from an external file.

For most of ARIA however, by assigning a particular role, you (the web page author) are making a pact with the user agent and assistive technology on the user's machine. For example, if you tell me something is a tree control, it should behave like a tree control and can only do so if you've implemented the JavaScript to control it. The user has no use for a tree control that is inoperable, so why even tell them it is a tree control unless the script that controls it is running. Instead, it's better to add that role to the element as part of the controller script's initialization. This way, it's cached in an external file, and you can load the additional script conditionally if you choose to do so.

There is nothing to stop you from using the CSS expando property idea, though XBL might be a better choice in the long run, if those roles, states, and properties are added via the same controller script that assigns the event handlers for each widget.

David Bolter

Note that "role" is one of the few attributes used by WAI-ARIA that doesn't required the "aria-" prefix (at least at this time). Cheers.