[whatwg] Thoughts on video accessibility

Silvia Pfeiffer silviapfeiffer1 at gmail.com
Thu Dec 11 15:11:04 PST 2008

Another implementation comes from the W3C TimedText working group:

They have a test suite for DFXP files at
http://www.w3.org/2008/12/dfxp-testsuite/web-framework/START.html .

Philippe just announced that he added HTML5 video tag support using
the javascript file that Jan had written for srt support and adapting
it to work like this:

 <video src="example.ogv" id="video" controls>
     <text lang='en' type="application/ttaf+xml"

You'll need to use Firefox 3.1 to test it.
If you select the HTML5 DFXP player prototype, you can click on the
tests on the left and it will load the DFXP content.

The adapted javascript is at
http://www.w3.org/2008/12/dfxp-testsuite/web-framework/HTML5_player.js .

It works by mapping DFXP to HTML and DFXP styling attributes to CSS.
This is exactly what was also discussed yesterday on irc - if we can
find a simple way to map time-aligned text formats to HTML, it will be
easy to deal with in HTML5.


On Thu, Dec 11, 2008 at 9:57 AM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> And now we have a first demo of the proposed syntax in action. Michael
> Dale implemented SRT support like this:
> <video src="sample_fish.ogg" poster="sample_fish.jpg" duration="26">
>        <text category="SUB" lang="en" type="text/x-srt" default="true"
>                title="english SRT subtitles" src="sample_fish_text_en.srt">
>        </text>
>        <text category="SUB" lang="es" type="text/x-srt"
>                title="spanish SRT subtitles" src="sample_fish_text_es.srt">
>        </text>
> </video>
> Michael writes:
>> the demo: (tested on IE, Firefox, Safari ... with varying degrees of success ;)
>> http://metavid.org/w/extensions/MetavidWiki/skins/mv_embed/example_usage/sample_timed_text.php
> (bottom example)
>> If Firefox exposes timed text tracks in ogg media the script could query
>> them and display them alongside any available markup text tracks (but of
>> course other browsers like IE wont easily expose those muxed text tracks
>> so its likely the least common denominator of text based markup /
>> pointers will be dominate for some time)
> You will need to click on the "CC" button on the player and click on
> "select transcripts" to see the different subtitles in English and
> Spanish.
> Regards,
> Silvia.
> On Wed, Dec 10, 2008 at 3:49 AM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> I heard some complaints about there not being any implementation of
>> the suggestions I made.
>> So here goes:
>> 1. out-of-band
>> There is an example of using srt with ogg in a out-of-band approach here:
>> http://v2v.cc/~j/jquery.srt/
>> You will need Firefox3.1 to play it.
>> The syntax of what Jan implemented is different to what I proposed,
>> but I wanted to take it forward and make it more generic.
>> 2. in-band
>> There is also a draft implementation of srt inside Ogg through the
>> OggText specification, but I it's not released yet. It is also not as
>> relevant to this group as the out-of-band example.
>> Cheers,
>> Silvia.
>> On Tue, Dec 9, 2008 at 7:33 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
>>> On Tue, Dec 9, 2008 at 6:20 PM, Martin Atkins <mart at degeneration.co.uk>
>>> wrote:
>>>> Silvia Pfeiffer wrote:
>>>>> I'm interested to hear people's opinions on these ideas. I agree with
>>>>> Ralph and think having a simple, explicit mechanism at the html level
>>>>> is worthwhile - and very open and explicit to a web author. Having a
>>>>> redirection through a ROE-type file on the server is more opaque, but
>>>>> maybe more consistent with existing similar approaches as taken by
>>>>> RealNetworks in rm files and WindowsMedia files in asx files.
>>>> This (having a separate document that references other streams) is what I
>>>> was thinking of. I guess which is more natural depends on who is doing the
>>>> assembling. If it is the HTML author that takes the individual pieces and
>>>> links them together then doing it in the HTML is probably easiest.
>>> For what it's worth, loading an intermediate document of some new type which
>>> references other streams to be loaded adds a lot of complexity to the
>>> browser implementation. It creates new states that the decoder can be in,
>>> and introduces new failure modes. It creates new timing issues and possibly
>>> new security issues.
>>> Rob
>>> --
>>> "He was pierced for our transgressions, he was crushed for our iniquities;
>>> the punishment that brought us peace was upon him, and by his wounds we are
>>> healed. We all, like sheep, have gone astray, each of us has turned to his
>>> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
>>> 53:5-6]

More information about the whatwg mailing list