Re: accessibility of video element

At 15:33  +0200 4/07/07, aurelien levy wrote:
>I don't say that this working group must support one format more 
>than another. I just sat that open captionning is better for web 
>accessibility (technically  easier to parse for AT than burned in 
>captions even if actually there is any AT that can access to it, and 
>easier for user to manipulate). I think that the more simple is the 
>way to provide caption, the more content creator will add it.
>
>SMIL is very good but it's a pain to use.
>For example, to use it with a real media player in a web page i add 
>to integrate it with an object element.
>This object must have a .ram file src, this .ram file must containt 
>a link to  the .smil and then the .smil must link to the .rt for the 
>caption and the .rm for the video.
>
>At least i think the video element must support adding of the 
>current w3c timed text format DFXP :
>http://www.w3.org/TR/2006/CR-ttaf1-dfxp-20061116/
>(candidate recommandation)
>
>This way i can do :
><video src="xxx.rm">
><caption src="thecaption.dfxp" />
></video>
>
>or
>
><video src="xxx.rm">
><caption src="thecaption.rt" />
></video>

DFXP is an exchange format, not really designed for playback.  I 
don't mind adding "annotative" elements to video and audio, but I 
think it a mistake to make them an implicit SMIL 'par'.


>>>The model is that the content itself either has some kind of 
>>>accessibility "burned in" (e.g. burned-in captions), or can adapt 
>>>itself to an accessibility need.  That's it.  I think it would be 
>>>a mistake for HTML to try to get into the realm of media layup 
>>>languages, file formats, synchronization requirements, and so on. 
>>>These are properly the domain of SMIL and media systems.
>>>
>>>So yes, the media source is supposed to take care of this.  One 
>>>could reasonably embed a SMIL file as the target of a video 
>>>element, for example.
>>>
>>>Makes sense?


-- 
David Singer
Apple/QuickTime

Received on Wednesday, 4 July 2007 15:13:09 UTC