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

On Jul 2, 2009, at 11:02 PM, jfoliot@stanford.edu wrote:

>
>>
>> (1) Timed text tracks in the video file itself, with some form of  
>> user control offered.
>
> Will end users be able to 'extract' the text from the media asset  
> for repurposing (for example to Braille output device)? Will it  
> allow for text resizing (for low vision users), or re-styling via  
> CSS (adjusting foreground/background contrast aiding low vision and  
> dyslexic users, etc.)? It would be very interesting to see the full  
> proposal if it is public.

I don't think we've worked out the details. Timed text tracks are a  
standard part of MPEG-4 and other common media standards. I think any  
adjustment of the presentation of user needs would have to be by the  
UA or assistive technologies, not by author CSS.

>
>> (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. (*)
>
> While it is hard to be upset with a full-on accessibility strategy  
> (so don't misunderstand me), I suspect that this type of involved  
> solution would see little uptake from majority web developers.  
> Unless you are suggesting that sometimes specialty solutions *are*  
> acceptable... [mischevious grin]. However it is great news to hear  
> that Apple for one is pushing the envelope here.

I'm told by our media folks that there is video content out there  
where the only captioned form available is burned-in captions. In such  
cases, transcribing the captions to a text track would be a  
considerable burden, so we don't want to rule out using burned-in  
captions.

[...]

>
>> 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.
>
> Agreed - *if* the text can be extracted simply and natively. This of  
> course would also offer huge SEO benefits, as the transcript would  
> not be 'hidden' inside a binary file ( as is currently the case with  
> SCV files). I understand the desire to have everything wrapped up in  
> one 'downloadable' file, but I am also leary of any solution that  
> only sees captioning as a deaf / hearing impaired issue, which is  
> the initial impression I get from burned in captioning...

Search engines could look at text tracks in MPEG-4 files now, if they  
wanted to, since the way to do this is standardized, as I uunderstand  
it.

>
>> 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.
>
> Thanks for the update Maciej, here's hoping these types of solutions  
> are included in the draft - I think it would be incomplete to  
> approach Last Call without this type of solution in the draft - be  
> it the Apple suggestions or another.

I don't think any of these proposals would require a change to HTML5,  
since they all work using existing features.

Regards,
Maciej