HTML5 Doctor » Accessibility

Video: the track element and webM codec

Bruce Lawson — Thu, 24 Jun 2010 13:45:42 +0000

There are a couple of interesting developments in the world of HTML5 multimedia that you’ll be interested in. The first is the new element (currently only in the WHAT-WG spec due to political stuff).

is a child of a or element that links to a timed track, or time-based data. The kind of data is set via a kind attribute, which can take values of subtitles, captions, descriptions, chapters or metadata, depending on the type of information you’re adding to your media. These point to a source file containing timed text that the browser will expose via some kind of user interface, if the visitor requires additional data.

This will allow for “write once, use everywhere” accessibility; anyone linking to that file with a or element that includes the element can access your information.

The file format is a new format called WebSRT, which competes with about 50 other timed formats, including some W3C formats (hence the omission of from the W3C spec).

Added 9 July 2010: Here’s a readable overview of the SRT format.

Given that the format itself isn’t fully specified yet, it will be a while until we see implementation in browsers. But it’s good to know that there will be an official way to add accessibility information to media. Until then, I have a JavaScript hack to take timed s out of an in-page transcript to superimpose over a video.

WebM video format

The big news of the last month is that Google open-sourced the VP8 video codec that it acquired when it took over On2 Technologies. When combined with the Vorbis audio codec (that Spotify uses) and wrapped in a subset of the Matroska container format, it’s collectively known as WebM.

All YouTube videos are being transcoded to WebM, and Adobe have also announced they will include it in their Flash player. It’s available in an Opera 10.60 beta, a Firefox testing build, and a Chromium dev channel. Even Microsoft have said that IE9 will support it if the codec is installed on the computer.

The VP8 video codec itself is high-quality (Google had said that Ogg Theora wasn’t good enough compression-to-quality for YouTube, but Theora was based on the VP3 precursor to VP8). It’s available for streaming too.

If you want to encode to WebM, you can try the Miro Video Converter utility. Although it doesn’t allow you to optimise settings, it’s very easy to use. As the codec becomes more widespread, expect to see many more tools for content creation, editing, and transcoding.

Once production versions of the browsers are available, you should encode your videos with WebM as the first option, Ogg for older versions of Opera, Firefox and Chrome, falling back to royalty-encumbered H.264 for Safari and links to downloads or a Flash player for legacy browsers:






Your browser does not support video; download the WebM, mp4 or Ogg video for off-line viewing.

If, however, you’re having problems with the iPad, put the MP4 version first in the element; apparently there’s a bug that causes the iPad only to see the first element.

It’s a long haul, and it’s not over yet, but and .webM show significant progress towards our goal of accessible, open, and royalty-free video playing natively in the browser.

Share and Save:

Video: the track element and webM codec originally appeared on HTML5 Doctor on June 24, 2010.

Accessibility & Native Drag and Drop

Remy Sharp — Thu, 23 Jul 2009 13:30:32 +0000

A few days before my native drag and drop article came out Gez Lemon wrote about accessibility in drag and drop, and touched on HTML 5.

I then promised to look at implementing accessibility with native drag and drop, and here’s my findings.

ARIA Support

This was quite easy to add, though only by following Gez’s article. Since I already had events for drag start, I just needed to add drag end to clean up and remove the ARIA effects.

I added the following to the dragstart event:

addEvent(dragItems, 'dragstart', function (event) {
  // via ARIA say the element has been grabbed
  this.setAttribute('aria-grabbed', 'true');
  // code continues...

The added a new dropend event:

addEvent(dragItems, 'dragend', function (event) {
  // remove the ARIA grab attibute when we're not dragging
  this.setAttribute('aria-grabbed', 'false');
});

The effectAllowed and dropEffect combo was difficult to work out at first, though probably because I was playing with link and reference, whereas I should have been playing with move or copy. That said, a note about move and copy, move is a type of copy, with a clean up function to delete afterwards. Once I had this combo correct, the drop effects worked.

The changes required were to:

On drag: on all the drop targets add: setAttribute('aria-dropeffect', 'copy')
On drag: set the allowedEffect on the drag event: event.dataTransfer.effectAllowed = 'copy';
On drop: say what we’ll accept: event.dataTransfer.dropEffect = 'move';
On dragend: remove the drop effect from the drop targets: removeAttribute('aria-dropeffect')

The big problem for me was that I couldn’t truely test this.

Update: between the time I had finished my code and writing this article, NVDA (the Windows open source screenreader) announced that they recieved support from Yahoo!, and that ARIA drag and drop support is in their development roadmap.

The full working version of native drag and drop with ARIA support is available here: native drag and drop with ARIA support (source code)

Keyboard Support

Keyboard, sadly, is a whole different story.

I was able to replicate a lot of the keyboard features that Gez included in his demo. This included setting the tabIndex = 0 to allow the elements to tab to (superb trick by the way), included highlighting the drop targets as we drag.

However, the problem was: I wanted the user to be able to start the drag operation using the keyboard. Initially looking at the spec I couldn’t see that it was supposed to be supported (which it turns out, it is).

I started going down the path of using the keyboard to trigger drag events. I was able to replicate the drag event being triggered from the keyboard (like space starts the event), however, and this is a biggie, I couldn’t replicate the dataTransfer object. I tried faking it. I tried giving it nothing. I tried all kinds of random attempts to trick the browser in to giving me the object. It’s a no goer.

As it turns out, there is keyboard support written in to the spec (though in my personally opinion it’s not completely obvious to an author reading). The drag and drop operations should work like a copy and paste operation.

This is very clever, and I like it. Tab round to the dragable element, copy using the keyboard, which triggers the dragstart event, which I can then add classes to the drop targets, and make them tabbable. The user then tabs round to the drop targets, and pastes. This triggers the drop event and we’re all good.

No browsers support this keyboard event model.

I’ve raised bug for Mozilla and Webkit. They’ve both had comments on, and in both cases I’m not 100% sure what the comments mean, but speaking to the people involved via IRC, they’ve both said if it’s in the spec, it should be in the browser.

Let’s hope they do something about it. Now, how do I report a bug in IE…?!