Future Web Accessibility: HTML5 <video>

This is the first in a multipost series about the immediate and likely future of web accessibility. Each week or so I’ll discuss a different upcoming technology, tag, platform, or system from an accessibility perspective. Additions, corrections, or further thoughts are welcome in the comments.

The <video> tag

Although popular web browsers have had built-in support for inline images since the early ’90s, embedding video into a website has always required a third-party plugin, with the quality, user interface, and accessibility of the result depending largely on which video plugin or system was used. With HTML5, the web finally gains an official <video> tag, representing built-in browser support for playing and interacting with internet video.

Browser Support

The <video> tag got a lot of press recently after the announcement by Microsoft that the next version of Internet Explorer (IE9) will have <video> support. Since all other major browser vendors have already announced or completed the same, this means that the new <video> tag will eventually be supported almost everywhere. Sort of. Complications arise because the various browsers can’t agree on what video codecs they’re going to support, so actually using HTML5 <video> on the web is currently much more difficult than it should be. Assuming that gets worked out, it will still be some time before IE9 is finished (MS isn’t committing to a specific date yet) and several years after that before the majority of Internet Explorer users upgrade to the newer version.

Accessibility

The general theme of <video> accessibility is “lots of potential,” meaning that it could improve things greatly, but we’re waiting on the tag specification and browser implementations to be finalized before we know for sure. Two of the biggest issues right now are keyboard accessibility and captioning support.

Keyboard control

One of the biggest problems with existing media plugins is the poor (or sometimes complete lack of) support for keyboard accessibility. By default, HTML5 <video> uses playback controls provided by the browser, which should allow for easy keyboard navigation and control. While it’s still too early to know if all the browser makers will implement this correctly, it’s likely to be a big improvement over what we usually see today. (HTML5 also allows the page author to use custom video controls, which would need to be made keyboard accessible by the creator; these could also be used to get around any inadequacies in the default browser controls, though hopefully that won’t be necessary).

Captioning

The short version is this: the HTML5 <video> tag does not contain any built-in mechanism for captioning, descriptions, transcripts, or other synchronized media alternatives. The current draft of the specification says,

“To make video content accessible to the blind, deaf, and those with other physical or cognitive disabilities, authors are expected to provide alternative media streams and/or to embed accessibility aids (such as caption or subtitle tracks, audio description tracks, or sign-language overlays) into their media streams.”

In other words, people wanting their captioned video are basically on their own, or at least won’t get any help from HTML5 directly. Now, this technically isn’t any worse than the situation we have today, but isn’t any better either, and could potentially make the web a less accessible place if people using captions with existing video plugins (most of which have some level of caption support) switch to HTML5 and lose the captions in the process.

This has (obviously) created a quite a bit of concern in the accessibility world, and a lot of people have been (politely, we hope) urging the working group to add this functionality to the <video> tag itself. The W3C’s HTML Accessibility Task Force is aware of the problem, and is working on a solution, which might be including a subset of the (somewhat large) Timed Text/DFXP spec into HTML5 for use with the <video> element. This is all happening right now, with a resolution expected very soon (which probably means a few months, since we’re talking about the W3C here).

The Bottom Line

To summarize: HTML5 <video> allows native video on the web without requiring a third-party plugin. Will be supported by all major browsers soonish. Codec issues annoying, but don’t affect access very much. Keyboard accessibility should be very good (we hope). No built-in captioning features yet, but likely to be added shortly.

Further Reading

• The video element – HTML5 [whatwg.org]
• Multimedia Accessibility <Audio> <Video> [w3.org]
• Video on the Web – Dive Into HTML5 [diveintohtml5.org]
• Introduction to HTML5 video [opera.com]
• Everything you need to know about HTML5 video and audio [opera.com]