What improvements to accessibility are offered by HTML5?

Question

What benefits are offered by HTML5 over HTML 4.01 or XHTML 1.0 Strict for accessibility?

Answer 1

Some stuff that comes to mind - there's probably lots more:

The most important thing to note about accessibility in HTML 5 is not so much features as a change in philosophy. HTML 5 goes to some trouble to encourage web authors not to put information into places where ordinary users can't see it, such as alt and summary attributes, and instead encourages them to put the information into the normal body text. The idea is that (a) often the information hidden in these attributes is useful to sighted and non-sighted people alike and (b) if the author can see such text when maintaining and testing their page, they're much more likely to keep it correct and up-to-date than if it's hidden away. So for example, it defines a "figure" element that allow a picture and caption (i.e. the "legend" element) to be associated with one another.

In many cases, it is better practically for text that would previously have been put in the alt attribute to be put in the legend element, although it should be noted that theoretically they are different - alt is equivalent text - legend is auxiliary text. The same applies to the summary attribute and caption element on tables. Use of the caption element is encouraged over the summary attribute, but they don't serve exactly the same use cases. This has recently been the subject of a substantial dispute, with the current situation being that @summary is defined as being "obsolete but conforming", whatever that means.

Perhaps the best accessibility gain in terms of features in HTML 5 is the on-going process of integrating WAI-ARIA, the Accessible Rich Internet Applications Suite (http://www.w3.org/WAI/intro/aria).

I believe there's a new algorithm for implicitly associating table cells with their headers cells for screen readers to use which may save work having to specify the associations explicitly.

There's also some problems. The new "video" and "audio" elements have no HTML level fallback - it's assumed that accessibility fallback will be embedded directly into the video and audio files. This is a matter of ongoing dispute. Speaking personally as a web author, I know how to write a transcript of an audio file into HTML, but I don't have a clue how to embed fallback text into a pre-existing audio file. So while it may be a superior solution to place the fallback into the audio file, it many cases it's just not going to happen, and those who can't experience the audio directly will be the losers.

The new "canvas" element is also currently a big accessibility problem. Although some there are ideas about what to do, it's not at all clear whether "canvas" can ever have a truly accessible equivalent.