W3C home > Mailing lists > Public > public-html@w3.org > July 2009

Re: Shifting gears for a second (was RE: Codecs for <video> and <audio>)

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 02 Jul 2009 20:14:51 -0700
Cc: 'Sam Ruby' <rubys@intertwingly.net>, 'Ian Hickson' <ian@hixie.ch>, 'Doug Schepers' <schepers@w3.org>, 'Robert O'Callahan' <robert@ocallahan.org>, 'David Singer' <singer@apple.com>, 'Joe D Williams' <joedwil@earthlink.net>, public-html@w3.org
Message-id: <558305D5-D8BD-422D-80DE-190D4151E1FE@apple.com>
To: John Foliot <jfoliot@stanford.edu>

On Jul 2, 2009, at 8:01 PM, John Foliot wrote:

> Maciej Stachowiak wrote:
>> If you're willing to encode video files twice, the following markup
>> [1] will provide embedded video with CSS stylability and a consistent
>> JavaScript API in the latest versions of Firefox and Safari, and in
>> upcoming versions of Chrome and Opera, and likely in other upcoming
>> WebKit-based browsers for mobile platforms:
>> <video>
>>     <source src="example-video.mp4" type="video/mp4" />
>>     <source src="example-video.ogv" type="video/ogg" />
>> </video>
> This observer is, of course, concerned how/where the captioning  
> piece is
> in this example, and further where captioning is in the current spec.
> In an earlier note from Silvia Pfeiffer,
> [http://lists.w3.org/Archives/Public/public-html/2009Jun/0667.html]  
> she
> noted that:
> 	"... it has been decided that the first version of HTML5 <video>
> (and <audio>) will not have an in-built solution for captions, audio
> annotations and the like, because it is possible to do such with
> javascript and external files."
> Really?  Who actually 'decided' this, as I for one would certainly not
> take that lying down.  Was the WAI PF consulted on this piece of  
> decision
> making?  Or was it once again a back-room, IRC 'consensus' of a few?

Apple has proposed to support <video> captions in the following ways  
(I don't know offhand if any of these work yet in current versions of  

(1) Timed text tracks in the video file itself, with some form of user  
control offered.
(2) Alternate video files with "burned in" captions, selected  
according to user preferences and using the media="" attribute of the  
<source> element, with some extensions we have proposed for  
accessibility preferences. (*)
(3) Manually adding captions using JavaScript and time range events.

Of these, I think a timed text track in the video is the technically  
best solution. That way, accessibility is built into the media file  
itself, regardless of viewing context. But all of these options should  
be available.

We've also looked at the possibility of captions as an external  
annotation in some declarative form, but I don't think we've proposed  
a concrete solution along these lines.


* - Media queries for accessibility preferences also enable other  
possible alternate accessible forms of the video, such as high- 
contrast versions, or versions with an audio track that has background  
sounds and music removed, and leaves only speech.
Received on Friday, 3 July 2009 03:15:35 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:47 UTC