HTML5 and Accessibility

Accessibility for people with disabilities is a legal responsibility in many countries. It's also the right thing to do, and one of the characteristics distinguishing professional developers from the WWWs: WYSIWYG-wielding wannabes. But for many, accessibility has been a somewhat black art, requiring adding extra stuff to your code like alt text, table summaries, ARIA information that can be difficult to test by developers who are not assistive technology users themselves.

The arrival of HTML5 has further muddied the water. For some, HTML5 saves the world. For others – including many accessibility practitioners – it is the embodiment of evil.

In fact, as you've probably guessed, neither of those extremes is accurate. But the accessibility story of HTML5 is pretty good.

One of the primary ways to help users of assistive technologies (as well as boost your search engine rankings and improve your karma) is to use semantic markup—using the right element for the right content, describing meaning rather than presentation.

Previously, to mark up landmarks on a page - header, footer, navigation blocks - the only available element was the <div>, which has no semantics of its own. So while screen readers like JAWS have useful keyboard navigation that can allow users to navigate around HTML headings, lists, blockquotes and tables, there isn't an easy way for them to offer the ability to jump between navigation blocks, because there wasn't a unique element for the screen reader to hone in on.

HTML5 extends HTML 4's repertoire of elements considerably – for applying semantics to structural areas of a page we have <header>, <footer>, <nav>, <article>, <section>, <aside>, and<figure> to supplement our old friend, <div>.

So we can replace this div-only structure (which is the only one possible in HTML4)

with one using some of the new HTML5 elements:

Now, if a screen reader or other user agent wants to offer the opportunity to jump straight to<nav> (or skip over it) the semantics exist in the page. This isn't only advantageous to accessibility. For example, a browser could offer a print function that only prints content in <article>s, therefore missing out <nav> blocks etc that are entirely superfluous in print.

It's important to note that these browser features don't yet exist, but the possibility is there because we can now markup these important site landmarks with made-for-purpose semantics.

For more on the new HTML5structural elements, see my article: Redesigning with HTML 5 and WAI-ARIA and Emily Lewis' Using HTML5's New Semantic Tags Today.

WAI-ARIA

The benefits of HTML5 structural elements aren't available yet. But many assistive technologies can already make use of a similar method to denote important structures on a page called WAI-ARIA. ARIA isn't part of HTML5; it's a specification written by the W3C so we won't look at it in great deal (see Gez Lemon's Introduction to WAI ARIA for a great primer) but one of its central concepts is of Document Landmark Roles - marking up important landmarks on a page. ARIA uses attributes rather than elements, as it's designed to supplement any markup language, not just HTML—it can be used with SVG, Adobe's MXML.

Here's our sample HTML4 page supplemented with ARIA:

Adding ARIA information to HTML4 helps accessibility, but it won't validate. Because HTML5 is still in development, ARIA attributes will validate in HTML5. Not only that, there are certain correspondences between the two specifications in the HTML5 spec; some elements have built-in ARIA roles that can't be over-ridden.

The HTML5 validator "knows" about these, too, so the validator will laugh in your face if you try to code <header role=navigation or <footer role=banner>This is "A Good Thing" and an advantage over using HTML4 in which ARIA is invalid, even if you use no more HTML5 features. Be careful, though; the mapping of ARIA and HTML5 is still being discussed and the validator is very likely to change.

Multimedia accessibility

One of the aspects of HTML5 is the native multimedia features it offers. All browsers offer built-in video controls (play/ pause, seek bars, volume controls) just as they do scrollbars, form controls etc. That the multimedia is native rather than handled by a plugin is advantageous for accessibility because the media is part of the browser. Opera and Firefox offer native controls that are accessible to keyboard users. (Many people with motor or visual impairments can't use a mouse.)

The HTML5 media elements API allows developers to script their own controls. If you do this, we strongly encourage you to use semantic elements like <button> for play/ pause toggles and the new HTML5 form input mechanism <input type=range> for a volume slider, as these are keyboard-accessible by default. As a starter, check out Patrick H Lauke's fancy video controls, and note that behind the CSS3 transition, opacity, web font for the timings, we have basic HTML4 form elements and a slider, courtesy of HTML5 input type="range" :

<div id="controls"> 
  <button id="playpause"> 
    <img src="play.png" width="15" height="15" alt="play"/> 
  </button> 
  <output id="display">0:01:55</output> 
  <img src="audio.png" width="15" height="15" alt="volume" id="volumeicon"/> 
  <input type="range" min="0" max="10" id="volume"/> 
</div>

Of course, the ability to control the video or audio is only useful if the user can actually perceive the contents. The Working Groups are still working on a mechanism to add captions, subtitles, karaoke lyrics and the like, using a new <track> element like so:

<video controls>
<source src=movie.webm>
<source src=movie.mp4>
<track src=english.vtt kind=captions srclang=en>
<track src=french.vtt kind=captions srclang=fr>
<p>Fallback content here with links to download video files</p>
</video>

This example associates two caption tracks with the video, one in English and one in French. Browsers will have some UI mechanism to allow the user to select the one he wants. The <track>element doesn't pre-suppose any particular format, but the browsers will probably begin by implementing the new WebVTT format, which was based on the .SRT format. This format is still in development by WHATWG, with lots of feedback from people who really know, such as the BBC and Google, the organistion with probably the most experience of subtitling web-delivered video via YouTube.

WebVTT is very simple, but can also allow for bold, italic and colour text, Ruby annotations and vertical text for Asian languages, and positioning text on the viewport.

There's an excellent presentation by Dr Silvia Pfeiffer called WebVTT explained which we highly recommend. Silvia associates a WebVTT transcript with a video and, because browsers don't yet have native support for the API, she uses the open-source JavaScript Captionator polyfill to provide support.

The W3C is also working on Multitrack Media API specification which will allow non-textual accessibility information to be synchronised with media, thereby catering for s sign language tracks, audio description tracks, dubbed audio tracks, alternate viewing angles and similar additional or alternative tracks to the main audio/ video tracks. This is very new, and very exciting.

Canvas

Like other aspects of HTML5 accessibility, canvas accessibility is a work in progress. Features to support the authoring of accessible canvas content are still being specified and the features that are specified, only have limited implementation in browsers.

This does not mean that developers cannot also provide an accessible user experience when using canvas.

Canvas example:

<canvas id="example" width="260" height="200" role="img">
<p>A <a href="http://en.wikipedia.org/wiki/Rectangle">rectangle</a> with a black border. In the background is a pink circle. Partially overlaying the circle is a green square and a purple triangle, both of which are semi-opaque, so the full circle can be seen underneath.</p></canvas>

As in the example code above, HTML5 specification suggests alternative content can be placed inside the canvas element:

When authors use the canvas element, they must also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element.

This is currently not recommended, as access to content inside the canvas element is not well supported. The safest method is to provide an alternative presentation of the canvas content preferably on the same page:

Code example:

<figure>
<canvas id="example" width="260" height="200"></canvas>
<figcaption>A <a href="http://en.wikipedia.org/wiki/Rectangle">rectangle</a> with a black border. In the background is a pink circle. Partially overlaying the circle is a green square and a purple triangle, both of which are semi-opaque, so the full circle can be seen underneath.
</figcaption>
<figure>

Sometimes, as in the example above, the best alternative may be a description of what is going on in the canvas, this will be true for many of the cool demos showing the sorts of visualwizardry that can be accomplished using canvas. At other times the alternative may be the presentation in a different format of data displayed in the canvas. A good example of this is the Accessible ChartsjQuery plug-in.

For interactive canvas content, ensure anything that can be operated using a mouse can also be operated using the keyboard. It is recommended developers make use of native HTML5 controlsrather than custom UI controls drawn on the canvas, as users of assistive technology such as screen readers will not be able to understand or operate the canvas based UI controls.

Once canvas accessibility features are fully specified and implemented, more robust integrated methods for providing accessible canvas content will be available, so keep checking for the latest developments.

The two main canvas features that will aid accessible uses of canvas are a navigable canvas sub-DOM, and a draw focus ring method to indicate focus on an area of the canvas.

Having a navigable sub-DOM will mean any content within the canvas elements start and end tags will be available to users of screen readers. So even though they may be using a browser that supports canvas they can still be presented with alternative content if required. It will also mean that any interactive content with the canvas sub-DOM will be operable by keyboard users.

Using draw focus ring method developers will be able to associate a focus-able element , a link or control for example, within the canvas sub-DOM with a defined area on the canvas. When the element in the sub-DOM receives focus via the user tabbing to it via the keyboard or by using the JavaScript focus() method, the associated area on the canvas will have a visible focus ring drawn on it. This focus ring will also have its coordinates exposed via accessibility APIs so screen reading and magnification software will be able to accurately convey where the current focus is on the screen.

It is envisaged that developers will find it useful to script interaction with links and controls drawn on the canvas with real HTML links and controls in the canvas sub-DOM which will have the potential to make canvas interaction more accessible for all users.

So once these and other canvas accessibility features are fully specified and implemented, more robust integrated methods for providing accessible canvas content will be available.

Areas of disagreement

There have been many ill-tempered discussions about some attributes that were designed to aid accessibility being removed from the specification. These include the longdesc attribute of theimg element and the summary attribute of the table element.

longdesc is proposed for removal because very few websites actually used it and most user agents (browsers or assistive technologies) didn't expose it to the user. Those who wish to keeplongdesc argue that it has decent support in assistive technology, screen reader users find it useful (although less than two years ago the same survey found longdesc "very unpopular"). The killer argument is that it is used now, albeit by only a few, and it is therefore wrong to break backwards compatibility for those people.

summary is invisible metadata that is only meant to be exposed to assistive technologies. If a table has a complex structure that needs explaining to a blind user, then a user with cognitive problems, but who does not use a screen reader, could benefit from this information. As hidden data that is not visually apparent tends to fall out of sync with he rest of a page, using aria-describedbyand/ or the HTML5 details element is a better alternative.

Conclusion

HTML5 is not the accessibility disaster that some would have you believe. It tries to build accessibility in by design rather than bolt it on afterwards, and this is A Good Thing; if something is left to authors to add, they won't. Just look at how many images have no alternate text, or useless alternate text.

As the specifications continue to be refined, we'll see more changes. of course, it's not the specification which implements keyboard accessibility, or which actually passes information to the screen readers, screen magnifiers, narrators and refreshable braille displays that real people use - it's Web browsers. Steve keeps tabs on the accessibility of the various implementations atHTML5accessibility.com. Given the rapidity of implementation of HTML5 and the speed of iteration in browsers, we can optimistically expect a bright future.