Built-in or bolt-on accessibility in HTML5? How about a bit of both?
While following the development of HTML5 I’ve seen a fair bit of talk about “built-in” vs. “bolt-on” accessibility. Perhaps I’m missing something vital, but I don’t really see what the problem is or why it has to be one or the other.
Built-in accessibility by means of semantic elements and controls that browsers can do something meaningful with and expose to assistive technology is great. As long as web developers use the elements of HTML as they are intended, they get plenty of accessibility more or less for free.
On the other hand, we can’t have HTML elements and attributes that cover every imaginable use case. It also isn’t always possible, for various reasons, to change existing, non-semantic and inaccessible markup. That’s where “bolt-on” features like WAI-ARIA are also necessary – to make it possible to make UI elements created with non-ideal markup, CSS and scripting accessible.
In other words, we need both built-in and bolt-on accessibility.
There has recently been some talk about removing several of the new semantic elements in HTML5. I think that the more built-in semantics we can get, the better, so I support most of the reasoning in the counter-proposal to Retain several newly-introduced semantic elements, attributes, and controls. This sums it up pretty well:
Semantics are best expressed at the semantic layer (HTML), not at the presentation layer (CSS) or the accessibility layer (ARIA)
The elements and attributes that the change proposal discusses are figure, aside, details, hidden, progress, and meter. I think that for an interactive element like the details element, it would be good if the spec was more specific about how it should be interacted with or at least noted that it needs to be implemented in a way that makes it input device-independent.
- Previous post: Web Inspector adds Timeline and Audits panels
- Next post: Why iPhones, iPods and iPads are Flash-free