Some accessibility today or full accessibility jam tomorrow?

A very good friend of mine wrote to urge me not to promote the jCap jQuery plugin to generate overlaid video captions from a transcript.

The reasoning was that my proof of concept is a hack and we will soon have real specifications for Media Text Associations and a Media Multitrack API. Of course, those specs need to be agreed and—here’s the rub—implemented in browsers.

My friend also worries that by propagating a hack, I might entrench worse practice and therefore discourage adoption of the proper way. This argument is compelling. However, this worries me because it basically means that HTML5 videos would be inaccessible today by design, waiting for proper accessibility jam tomorrow.

What do you think is the right way forward? Hacking for accessibility now, in a manner that’s acknowledged to be not “proper”, or waiting?

12 Responses to “ Some accessibility today or full accessibility jam tomorrow? ”

Comment by kl

When new technique comes out, will drop-in replacement be possible? (i.e. if user just uploads new version of the plugin, will it start using “jam” api?)

I think it would be best if it were future-proof, so that switch to new technique is hassle-free.

Comment by Isofarro

Something that works right now in browsers is surely a far better option than waiting for something that might, or might not appear in the future. Future implementations are all vapourware until it’s implemented, and only useful when widely available.

Comment by Bruce


When the new APIs come on-stream, everyone will have to update their video elements anyway, to add new stuff for accessibility.

The temporary jCaps plugin takes a transcription on the page (not one pulled in as an .srt file within the extended video element) and makes captions from it.

So you’d need to remove the inclusion of the jQuery library (one line) as well as add all the new API stuff.

Comment by Shelley

We used DOM Level 0 event handling for years until the newer event handling came along. And we support Microsoft’s way in addition to the DOM method, and the older DOM methods.

Future proof your technique. If the media API is stable enough, show how the media API can be incorporated safely today, even if it isn’t implemented (object detection). Web developers are used to these situations.

One thing you don’t necessarily want to do, is establish a pattern of, “Well, don’t do anything until we say, OK?”

Comment by AlastairC

Is it possible to detect support for roles?

It would be really useful to be able to do something like:

if(@role.captions) {
# use API
else {
# use jCaps

Comment by Eric Meyer

Well, you know me: I’m always in favor of a hack that mostly works today in favor of a total solution that might work tomorrow. As Anne says, you can get valuable insight into how tomorrow’s total solution should work by experimenting with today’s partial solution.

Comment by Bruce

Wow, John. Spookytastic! Synchronicity indeed. (reckon you code up the wishlist?)

Alastair, Shelly; there’s no future-proofing possible, really. My technique merely requires a transcript with timestamps to be associated with the video element via aria-describedby. The JS library does the rest.

When the new way is implemented cross-browser, you just need to remove the line that calls in the library. And add the stuff for the new API, of course. The transcript will still be there for other readers and SEO.

Comment by Shelley

Bruce, without having a chance to look at the Media API or jCaps, and going by past situations of this kind, what I’m assuming will happen is the jCaps people will move ahead with their work now, but continue the work, even as the new Media API releases.

If the library provides a level of abstraction, then those people who are using the library won’t have change their interface, because all of the changing will happen within the jCaps library. The jCaps people might expand the library, and add new capabilities, but the earlier functionality would still remain.

Regardless, you never tell people to stop. If you do, you’ll have the devil’s own time getting them going again.

Comment by John McCollum

@Bruce, I’m happy to start bashing away at the wishlist. Most of it looks do-able, time allowing. I’m not happy with the way I originally wrote the API – it’s not jQuery-esque enough and I think there are some issues that will bite me on the bum further down the road.

I had also told your very good friend that I would pause development to get a full understanding of the issues, and a consensus over whether we should go ahead with this or not. It looks like it is something that will be useful, so I’m happy to proceed.

“Regardless, you never tell people to stop. If you do, you’ll have the devil’s own time getting them going again.”

Ain’t that the truth! :D

Comment by Silvia Pfeiffer

The only suggestion I would make to people who develop javascript libraries to provide captions to HTML5 media elements now is to not bury the captions inside the JavaScript, but to provide them in a “standard” text format. In the HTML5 accessibility task force we are discussing mainly SRT and DFXP (now also called TTML) as such standard formats. I would encourage to go with these so when the standards come out, it will be easy to switch. It would be terrible if all these experiments led to a gazillion of new pseudo-formats for caption listings that have to be transcoded again eventually.

Other than this, I concur with Anne – experiments are good and show that there is a need.