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.
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.
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.