Updates on the “ARIA stylesheet” hack

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.

  1. 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.
  2. 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">.
  3. 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.
  4. 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.

I'm currently available for hire, to help you plan, architect, and build new systems, and for technical writing and articles. You can take a look at some projects I've worked on and some of my writing. If you'd like to talk about your upcoming project, do get in touch.

More in the discussion (powered by webmentions)

  • (no mentions, yet.)