views:

1625

answers:

3

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

A: 

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.

Jared
Fair point on the lack of accessibility enhancements, but is that a reason to stick to HTML 4? I assume screen readers parse HTML5 just fine. (And if they don’t, hey screen reader vendors, how about a fricking software update.)
Paul D. Waite
It depends on what you mean by parse. Screen readers don't parse HTML, they get a model of the page from the browser after the browser is done parsing it. Most things should just work, the only area where screen readers need to support specific tags is in screen reader specific tags such as those found in the ARIA standard. http://www.w3.org/WAI/intro/aria.php
Jared
+14  A: 

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.

Alohci
That is a very good answer.
“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.” — is that still true? I thought you could stick whatever HTML content you want inside the `<video>` tag as a fallback, including a transcript.
Paul D. Waite
@Paul - I believe it still true, yes. As I understand it, the content inside the video element is only displayed in browsers that do not yet support <video>. Once a browser supports <video> it should never display or make available to accessibilty tools the contents of <video>.
Alohci
@Alohci — ah, gotcha. From your description, it does sound like you’re looking for an additional mechanism to be added to HTML to mark up video transcripts. From a rigidly technical point of view, it seems to me to make more sense to have one transcript, embedded in the video file. I’d rather the “I don't have a clue how to embed fallback text into a pre-existing audio file” problem be solved at the authoring tool level, rather than by adding more things to HTML.
Paul D. Waite
@Paul - Not necessarily a transcript, no. Like all accessibility content, what I'd want is to provide as close to *equivalent* content as is practical. While a transcript may be appropriate for some video, it's by no means suitable for all. For example, consider a silent movie. Is a transcript of that, the best equivalent content that can be provided?
Alohci
I see what you mean. Not entirely sure what HTML could helpfully do here though. You can still pop in links to HTML alternatives (transcripts, descriptions) right after the video tag.
Paul D. Waite
+4  A: 

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’

itpastorn