Comparison of Browsers on HTML5 Video Accessibility

Browser support for HTML5 video is constantly evolving, including support for accessibility features. Consider this a snapshot of the current state of accessibility support as of June 14, 2013. It may change tomorrow.

First, here’s the code one might use to add video to a web page, including captions, subtitles and text-based audio description:

<video controls width="640" height="480" aria-label="Video Player" 
  poster="screenshot.jpg">
  <source src="video.mp4">
  <source src="video.webm">
  <track kind="captions" src="captions.vtt" default label="English">
  <track kind="subtitles" src="subtitles_fr.vtt" srclang="fr" label="French">
  <track kind="subtitles" src="subtitles_es.vtt" srclang="es" label="Spanish">
  <track kind="description" src="description.vtt" srclang="en" label="English Description"> 
</video>

Some explanations:

• The controls attribute shows the browser’s default player controls. This is optional since some developers may want to create their own controls.
• There are two <source> elements, since browsers don’t all support the same video file formats. They’re coming around, but for now WebM is a reliable fallback for browsers that don’t support H.264 (MP4)
• The <track> element is used to synchronize timed text with the video. There are several kinds of track elements, as indicated by the kind attribute (I’m most interested in captions, subtitles, and description).
• Audio description is not supported by any browser, but the framework is there in the HTML5 spec for possible future support.
• The default attribute is (according to the spec) optional, but if included is intended to enable that track by default, e.g., to deliver the video with English captions turned on. My tests show that default is actually required; otherwise captions don’t work at all in Chrome, Safari, or Opera.

Also, the <video> element receives keyboard focus in all browsers, but in some browsers the video focus indicator is sorely inadequate (a thin dashed line) and it’s practically impossible to tell when the player has focus. For this reason I like to add a visual focus indicator using CSS, something like this:

video:focus { 
  border: thick solid yellow;
}

The observations described below were made with variations on this sample HTML5 video page, which features the AccessComputing video IT Accessibility: What Campus Leaders Have to Say.

Internet Explorer 10

IE is way ahead of the pack on HTML5 video accessibility. I specifically tested IE 10.0.9200.16618 in Windows 7.

Users can tab to all controls within the video player control bar, including the full screen button. Controls continue to be keyboard-accessible in full screen mode. Controls are relatively large and white on black, making them easy to see. When the mute button receives focus, a vertical volume slider appears and keyboard focus is routed to the new volume control, which can be operated with up/down arrow keys.

The player controls all have intuitive names (e.g., Play, Skip Forward, Full Screen) and very informative descriptions (e.g., Skip forward 30 seconds), all of which are exposed via MSAA. I tested with JAWS 14, which announces all of this information and also announces the button’s hotkey (e.g., space to toggle play/pause, shift + left/right arrow keys to skip back or forward, alt+enter to for full-screen mode).

NVDA doesn’t announce any of this information, but that’s an NVDA shortcoming, not an IE shortcoming, since the info is all exposed via MSAA.

IE supports captions, either in WebVTT or TTML format. It correctly handles the default attribute, so the default caption track is automatically on. If there are subtitle tracks, they’re bundled with captions and available as choices that can be selected via the CC button.

My only beef with IE is that the captions are displayed as shadowed text, not as text on a black translucent background. Consequently the text is hard to read unless the lower third of the video itself has a dark background. As far as I could find this isn’t user-configurable.

IE is also the only browser that has a control for playback speed, available from the context menu by right clicking on the video. This enables users to view the video at a range of speeds from 0.125X (super slow) to 8.000X (ultra zippy). Slowing down video is great for people with cognitive disabilities and for guitarists who want to slow down and study that fleet-fingered guitar riff, and speeding up video is great for people in a hurry.

Firefox 21.0 (Windows and Mac)

Firefox does not currently support captions or subtitles.

Otherwise, it’s a pretty accessible player. Users can’t tab to the various player controls like they can in IE, but all but one of the controls is accessible using keyboard combinations. These are fairly intuitive, and are all documented on Mozilla’s official list of Keyboard shortcuts for video in Firefox. The one button that is not accessible by keyboard is the Full Screen button.

For screen reader users, all the buttons are labeled (e.g., Play, Pause, Mute, Full Screen), but don’t have the detailed descriptions that IE has. Both JAWS and NVDA announce these labels. However, JAWS has a quirk where it announces the percent of progress with a bit more precision than most people need (rounded to the nearest 15th decimal place). Not sure who to blame for this behavior – NVDA doesn’t do it in Firefox, but JAWS doesn’t do it in IE.

Also of note, the Firefox gray-on-gray player controls have the worst contrast of all browsers.

Chrome 27.0 (Windows and Mac)

In Chrome, the video player cannot be controlled with keyboard. This is a known bug in Chrome.

The video player in Chrome is half accessible to screen reader users. With the ChromeVox extension installed and enabled, ChromeVox announces when the video has focus, at which point I can play it by pressing Enter (I tested with ChromeVox 1.27). Note that pressing Enter only works with ChromeVox enabled. Otherwise, again—no keyboard accessibility. Although I can play the video with ChromeVox, I can’t drill into the video to access individual controls. The experience with JAWS 14 is actually better—all controls are accessible and intuitively labeled. I describe this as only “half accessible” however because the controls disappear after a few seconds, and when that happens they disappear for screen reader users as well, and I was unable to restore focus to the player controls so I could pause or perform any other functions.

As for captions, well, caption support is a bit of a mess. Chrome does support WebVTT caption tracks, but it’s very buggy.

If a caption track is available, a CC button is added to the player. However, this button does nothing unless one of the tracks includes the default attribute (even if there’s only one track).

If you’re trying to play captioned video with local files (not on a web server), captions won’t play. Chrome is the only browser with this problem, so I’m pretty sure it’s a bug rather than a security feature. It does play local video, just not local captions. Confusingly, if the caption track element points to a local source and includes the default attribute, the player does not show a CC button; but if the default attribute is missing, a CC button appears but has no functionality when clicked.

All of these behaviors are the same if kind=”subtitles”.

Also, caption parsing seems to be buggy in Chrome. Captions occasionally drop out and are omitted altogether, or they spill out willy nilly onto the screen as in the following screen shot.

I discovered this problem while showing the Campus Leaders video during the keynote presentation at Accessing Higher Ground. Gotta love surprises like that!

According to the WebVTT validator, the caption file itself is fine, plus the same caption file works fine in IE (and other browsers, if the default attribute is present).

Safari 6 (Mac only)

Safari 6 is built into Mac OS X Mountain Lion, and is available for Lion in a software update. Previous versions of Mac OS X, and all versions of Windows, are stuck with Safari 5 which doesn’t support captions and doesn’t work with Windows screen readers. I didn’t even bother testing Safari 5.

Safari 6 is the same as Chrome in most respects. It supports WebVTT captions if the default attribute is present, but otherwise does not. There is no CC button to toggle captions on or off. The player cannot be controlled at all with keyboard.

Unlike Chrome, Safari does support local caption files.

I also find it interesting that the first button on the Safari control bar is the “Go back 30 Seconds” button, not the Play/Pause button. That isn’t necessarily a bad choice—just not one I probably would have made. Also there’s no “Go forward 30 Seconds” button. Again, not bad—just interesting.

Opera 12.15 (Windows and Mac)

Opera has always had good support for keyboard users, and the video element is no exception. Users can tab among all the player controls, just as they can with IE. When a control has focus it can be operated with the usual keys (Enter or space to toggle play/pause, left/right arrows to scrub forward or backward, up/down arrow to control volume).

Unfortunately Opera is not accessible to screen reader users.

Opera supports captions in WebVTT format. However, like Chrome and Safari, Opera only displays captions if the caption track includes the default attribute. Otherwise captions aren’t displayed, and there’s no CC button to toggle them on.

Summary

It’s great to see that video accessibility is supported at some level by each of these browsers, but clearly there’s room for improvement. The takeaway for me is that there’s still a compelling need for custom, cross-browser media players built to utilize the HTML5 media API. Stay tuned for more on that…