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? ”
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.
Experimenting with “hacks” usually generates valuable feedback for what we should do for their native variant so I would urge people to keep on doing this!
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?”
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
}
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.
More synchronicity Bruce, I blogged on *exactly* the same subject today! This is getting freaky! http://bit.ly/90G3GB
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.
@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.
@Shelley:
“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! 
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.
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.