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

Comments

  1. Tom

    Great post and idea, I’m looking forward to the series.

  2. Thomas Ingram

    I’m looking forward to implementation of HTML5 video. On the New York Times I’m unable to bring focus to their video player (using Firefox). I think the challenge for browser makers is how to make it clear the video has focus (for keyboard users) … perhaps a yellow border?

  3. Bill Griffiths

    Thanks for the timely update. I have to admit that I’m not optimistic about too many issues being left to the discretion of the browser developers. I still find it difficult to understand why the major browsers don’t support SMIL directly.

  4. Richard

    Though, it won’t be too far in the future. Upgrade cycles do run slowly. Look around. You’ll be surprised how many IE6 installations you still see.

  5. Florent V.

    A track () element was added to the WHATWG draft of HTML5 a few days ago. It’s intended for captions, subtitles, text descriptions (which could be voiced by a screen reader, theoretically), and script data.
    Regarding the format for timed text, they apparently snubbed TTML and opted to adapt the SubRip (SRT) format with some modifications maybe, to create a WebSRT format. This is very young so we’ll see what the outcome is in the next few weeks.

  6. Webstandard-Blog

    Thank you very much for those informations. If you read articles about HTML5 you can suppose that the video-Tag is going to be the most interesting & important new feature for most of the users.

  7. Sunshine

    An interesting article about HTML5, thank you:)

  8. Thomas

    The WHATWG spec proposal for a track element looks promising and should also be easy to implement in browsers, but since there are obvious political issues around the W3C draft, it could very well be several more years before we have a majority of browsers with subtitle support.

    Personally I found that rather disturbing since HTML5 video is now being implemented across many large websites – this is not something that should have to wait. So I did something about it: VideoSub is a library that looks for track tags in HTML5 videos and if the browser does not have track support it will load and display the subtitles: http://www.storiesinflight.com/js_videosub/

    The idea is for web developers to be able to implement SRT subtitle support with track tags right now based on the WHATWG spec proposal, with the VideoSub library gracefully stepping back once browsers have native support.