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

From a practical standpoint it offers no accessibility enhancements. None of the screen reader venders have implemented support for the new tags, and won’t until there in wide enough use to make implementing that support worth while. If you want to make your sites accessible don’t view HTML 5 as a magic bullet, use good old html 4 and follow good accessibility guidelines.

Answer 2

Let me say "hear, hear" to Alohci and provide a bit further detail:

One must remember that to browsers and assistive technologies there is but one HTML (except for MSIE 8). That means that a new version of the standard in itself does not mean anything, until implementations support the features. E.g. the longdesc attribute has been part of HTML 4 for more than 10 years, but has zero support, and is thus not usable at all.

Potential benefits in the HTML 5 standard are:

• New elements that can make skip-links redundant. Since these new elements are less crufty than ARIA landmarks, that also have this power, they are likely to see more adoption. I.e. Authors might not realize that they are making a page more accessible, they just want to use the best available tags. User agents may use these new elements to facilitate easier navigation, and that can be a benefit to more people than the blind.
• For a number of uses where accessibility can not be built in, but has to be bolt on, ARIA is available. Just the other day the first edit was made to the draft to include ARIA!
• Video and audio, SVG and Canvas can be used in ways that will help people with cognitive disabilities. (At the moment the best way of integrating SVG in plain HTML is still being debated, though.)

There are still matters that are unsolved though:

• Captioning for video. So far the only option is JavaScript, a rather ugly bolt on solution that is very unlikely to see high adoption rates. OTOH, how many videos on Youtube are captioned today?
• Screen reader accessible content from Canvas objects. The beauty of Canvas is that it has no DOM, but that is also is main shortcoming. There is no solution for everybody in this regard. What if you'd implement Tetris, Pacman or Doom using Canvas? These games will always be inaccessible to a screen reader user due to their very nature. Bespin, OTOH, should be made accessible to them.

SVG has a DOM and can thus be seen as a screen reader friendly alternative, but currently there is little support implemented in them.

There are some minor debates still going on as well, such as:

• Is it preferable to make the alt attribute optional, in the hope of reducing badly written alt-texts, or to keep it required, in the hope of forcing content contributors to write good alt-texts?
• Should the summary attribute be allowed and seen as the best alternative to describe complex tables, where caption, th, thead, tbody, tfooter and headers/id are not enough?

In one corner we have people mainly associated with the original WHAT WG effort, that are building their argument on the fact that today's usage of these features is abysmal. When they are used, most authors get them wrong. One should not have high hopes that education will work any better in the future. I call this group elitistic but pessimistic.

In the other corner we have the accessibility (and lately also the RDFa-lovers), that are building their case on expertise in the subject area. They are aware of the huge potential benefits there are in correct usage of accessibility features. They are optimistic about education efforts, but might come across as a bit fanatical in their reasoning.

Beyond the debate HTML 5 will mean that to knowledgeable authors 99 % of their accessibility toolbox is still usable, and they have a few more tools to use, but also a few more challenges to overcome. ‘plus ça change, plus c'est la même chose’

Answer 3

I am not blind or deaf or officially disabled at all but I am absolutely friggin sick of using websites. After 15 years of dragging a mouse around the screen and watching the navigability of websites decrease as my arms and wrists have become increasingly sore is making me depressed!! There are simple solutions which could be built into any new standard. The 'hit'a'hint plugin' for firefox was great but not always updated. I like the very similar new 'ALT' shortcuts with the MS ribbon interfaces, they are a godsend, although I do not think it will get me back from Linux. How difficult would it be to have inbuilt shortcuts in HTML 5.0. You hold a key, it gives you a keyboard cut to hit... absolutely simple. This could prevent tens if not hundreds of millions of people from developing long term arm and wrist damage in the future. My own problem did not start until after 20 years of computer use and 10 years of mouse use, so there is a potential time-bomb ticking here.

Answer 4

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.