Comments on: The most pressing Accessibility issue in HTML5 today?

By: Joe Clark

Joe Clark — Fri, 31 Jul 2009 03:31:02 +0000

I think the Timed Text Working Group, or whatever it’s called now, is run by a spook (intel agencies want to mark up voice-recognized text and intercepted messages); I haven’t looked at its specs (beyond once two weeks ago for five minutes) in like six years; AndrewWK at Adobe (a WGBH alum), along with WGBH and its many acolytes, will push the thing through as a spec right away.

YouTube will continue to ignore it and continue to publish self-congratulatory blog points about their atrocious “solution.”

dotSub and Subply and TED and the other crowdsourcing acolytes will continue to devalue the actual practice of captioning, a decline hastened by – wait for it – WGBH and NCI when they laid off their own staff circa three years ago.

Also, pretty much anything I say is going to get ignored anyway, or get criticized as an assault on the free market by redhead Objectivists. And I’m not being paid to work on this. Everybody else is. Even Pfeiffer.

So that’s my valuable input. I don’t know whether or not DXFP or whatever it’s called will be any good, but in every other facet of this issue my aphorism, varied slightly here, holds true: Everybody is walking around thinking the 4/5 of the problem they understand is the whole problem, and they’re about to announce a miracle solution for it.

By: John

John — Wed, 29 Jul 2009 21:59:31 +0000

@lachlan The W3C has released a Working Draft for a Timed Text format called DFXP (http://www.w3.org/TR/2009/WD-ttaf1-dfxp-20090511 ) which has been worked on by such groups as Apple, the BBC, Microsoft, RealNetworks and WGBH’s National Center for Accessible Media (to name some contributing authors). It is scheduled to go to Last Call very soon, so if you have ideas and/or concerns about this W3C emergent standard, please do lodge your issues with the appropriate Working Group.

My understanding is that the two front-running codecs (Ogg and H.264) have no issue with DFXP per se (and in fact, David Singer of Apple was part of the author group, and Apple is the main proponent for H.264…), so that particular argument rings a tad hollow as a barrier for captioning implementation (unless it is once again a WHAT WG N.I.H. argument)

You don’t want to “rush into” anything in HTML5, then why is HTML5 “rushing” into the element when the element is half complete? You suggest that adding something to the draft spec now would likely be an inferior solution, yet in many other areas of the draft specification there are existing but inferior suggestions already – items that are flagged as “…close but until we can return to it…”, so from my perspective better an inferior solution than no solution, which is what we have now.

@Joe there was a reason why I used single quotes on that term Joe… Technically files such as .M4V (which is the preferred file format for the iPhone) are re-processed (re-burned?) to include the binary .SCC caption file as part of the single downloaded file, making further extraction of this data nearly impossible, and thus inaccessible to Adaptive Technology such as Braille Output devices.

Do you have any concrete solution to propose as a way forward? Your years of experience in both captioning and web accessibility make you well positioned to offer valuable input – what say you?

By: Joe Clark

Joe Clark — Tue, 28 Jul 2009 22:13:23 +0000

“Burned in,” John? This isn’t hardsubbing we’re talking about.

By: Lachlan Hunt

Lachlan Hunt — Tue, 28 Jul 2009 09:36:22 +0000

The problem does not lie directly with HTML5. The problem lies, in a very large part, with the lack of an agreed upon standard of time text formats for captions/subtitles that is supported in container formats that works in various container formats (even when looking at just Ogg and MP4), and which adequately addresses all of the requirements that captioning and subtitling entail, including language selection, styling (fonts, colours, positioning, etc.) and whatever else.

These things take time and experience to develop, and we simply can’t rush into it with HTML5. There are people working on finding a suitable solution, but if we were to add something to the spec now, it would very likely be an inferior solution. It is far better to work on developing a good solution than simply whinging about it currently being absent from the spec.

By: John

John — Mon, 27 Jul 2009 04:50:28 +0000

@Michael – exactly right: until we have a common carrier, we can’t standardize on a common method of ensuring captioning. However the current “..we’ll defer to later” position is unacceptable.

Re: your question – I don’t know, but will look to test this week – stand by for results (unless somebody already knows…)

By: Michael Kozakewich

Michael Kozakewich — Mon, 27 Jul 2009 00:52:45 +0000

If I went to a site that had an html5 video, would I be able to stop it half-loaded by pressing the stop button on my browser?
If not, that’s something that needs to be implemented, too (and it’s also accessibility, after a fashion). I can stop big pictures from loading, so I should be able to stop big videos.

Meanwhile… I have a feeling that some vendors just aren’t going to go ahead with the video tag. When you get right down to it, that’s what we’re waiting on.
If the vendors can all agree on the codec and decide that they’ll implement video in their next browser (those who haven’t already), we might see more of a push towards getting the rest of it completed.