I’ve recently been struck by a parallel: the differences between usability and accessibility are very similar to the differences between writing the HTML5 spec and covering accessibility requirements.

Creating the HTML5 spec is like usability practice

I haven’t been following the HTML5 progress very closely (how much time does that take?!), but skimming the surface, the friction between developers in the ‘accessibility community’ and some of the core group developing HTML5 is obvious.

Usability tries to optimise for the majority. Techniques such as usability testing (with a representative sample) are oriented around getting the best results for the least expense. The changes to the interface based on usability testing should be kept simple and consistent for the majority of people.
I would guess that writing a spec is also an exercise in trying to keep things simple and coherent.

Accessibility overlaps a lot with usability, and historically web-standards + usability = accessibility.

However, there can be a few things missing, such as alt-text and making sure the keyboard focus is visible. These don’t get noticed by the majority of people, but are needed for people with particular requirements.

During the creation of HTML5 there have been several arguments around what is needed for accessibility, such as whether to make alt text required, and whether table headers are needed.

I completely understand that it’s very difficult to create an understandable, cohesive spec for HTML, so everything possible has to be done to minimise the complexity. However, accessibility is something that has to be included in such as way that developers and authors can create all their content in a way that is accessible.

For example, although complex tables are rare, it is necessary that they can be created in a way that works for everyone. Otherwise Governments and Financial institutions that have to publish content accessibly will have to go elsewhere. (Such as PDF.)

Jeremy Keith summed this up well in 2007:

I am more than a little concerned at the way that studying existing behaviour is being held up as a make-or-break point in discussions around HTML5… By their very nature, accessibility concerns are not going to affect the majority of users.

So yes, it’s useful to pave the cowpaths when you know the common ground, but sometimes you also add another path for those that need it.


There is an argument brewing about whether HTML5 makes WAI-ARIA redundant, and a plea for clean mark-up.

I agree that simpler markup is better, and that native controls tend to work best. I wouldn’t want to use something that creates front-end code based on Java people have written. However, some people (at rather large companies) do, and so you get the lowest common-denominator crap code that Steve Falkner pointed out.

So yes: it would be better if people like Google used cleaner code. However, even if browsers improve the styling of elements so that Google doesn’t feel the need to use krufty code, and HTML5 arrives, we are not there yet.

Working only on a future spec where the native controls don’t exist yet is kind of like saying to people with disabilities: “Don’t worry about your internet access for now, you can have intermittent dial-up for the moment, and we’ll get you broadband in a few years.” That doesn’t cut it.

There are several reasons why WAI-ARIAis needed:

  • It bridges a gap highlighted by modern web apps.
  • It can be added now without causing compatibility issues.
  • It can be added at a function level (e.g. to GWT and JavaScript libraries).

There is another important reason though: It should help simplify the HTML5 spec.

Should HTML5 cover all the elements in WAI-ARIA? For example, should there be a ‘tab’ element that HTML authors need to know about?

There isn’t, and I think that’s ok.

I’ve been reading into this more, and would like to modify my stance. The trigger was this: Semantics are best expressed at the semantic layer (HTML), not at the presentation layer (CSS) or the accessibility layer (ARIA), and the realisation that this is the built-in approach, where as WAI-ARIA is the bolt-on approach.

One thing I’m not clear on though, is what approach JavaScript libraries should take. Historically, people creating (web) applications have been really, really awful at using the limited HTML 4.01 semantics properly. Is adding more elements going to help that? Something like WAI-ARIA can probably be built into a Library more easily than adjusting elements dynamically.

3 contributions to “HTML5 and WAI-ARIA

  1. ARIA doesn’t solve anything until it is specified, integrated, implemented, tested, iterated and widely supported. It has had years to do this and still isn’t there.

    The real solutions could already have become the ones that work today. If only had ARIA not been distracting (and frequently detracting!) from them.

    ARIA is not a solution for the here-and-now. It is a cause of there still being a problem in the here-and-now.

    Incidentally, HTML5+ARIA integration was underway in late 2008. How can ARIA be making the HTML5 specification simpler when this has taken over 2 years, so far?

  2. Hi Ben,

    I feel I should point out that ARIA definition and support is progressing very quickly (compared to just about any other W3C spec), but I’m fairly sure you know that already. E.g. IE8 has some support for ARIA, but none for HTML5.

    I’ve seen no evidence that WAI-ARIA has distracted or detracted from other specs. What has been very difficult is getting accessibility requirements taken seriously by some people.

    A key quote from later in that thread is:

    we can’t just afford to punt on the concept of a directly accessible <canvas> … In HTML 4.01 the W3C made similar errors with JavaScript and CSS and said you had to be accessible with either technology turned off. Developers were saddled with these handcuffs for over a decade.

    I don’t see things in HTML5 that could have made web applications accessible today. That’s not a criticism, these things take time. However, you have to try and minimise the gap between new technologies (e.g. AJAX applications like Gmail) and being able to make them accessible. WAI-ARIA fulfils that.

    ARIA can make HTML5 simpler because it covers things that HTML5 doesn’t. It also appears that Hixie is waiting for ARIA:

    Yes, the plan is to make sure ARIA and HTML5 work well together. Right now I’m waiting for ARIA to be complete … Once that is cleared up, I expect HTML 5 will give a list of conformance criteria saying where ARIA attributes can be used and saying how they should be implemented in browsers.

    I think that’s fair enough, as there’s probably more than enough other considerations for the editors to deal with, and the people working on ARIA will have better experience with accessibility issues.

    So the question for you is: What things haven’t happened that would make ARIA redundant?

    By the way, I couldn’t see anything directly relevant from your link, perhaps ARIA in HTML5 integration is more relevant.

Comments are closed.