Re: accessibility of video element

At 14:44  +0200 4/07/07, Charles McCathieNevile wrote:
>On Tue, 03 Jul 2007 09:52:00 +0200, Dave Singer <singer@apple.com> wrote:
>
>>At 23:21  +0200 2/07/07, aurélien levy wrote:
>>>Is anybody have ideas about this issue :
>>>
>>>- Actualy i see no way to have synchronized 
>>>caption and audiodescription on video element 
>>>(except from directly embed caption or 
>>>audiodescription in the video itself) or is 
>>>the media + source element here to achieve 
>>>things like that ? why did not you take the 
>>>SMIL audio and text element ?
>>>
>>>Aurélien
>>
>>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?
>
>In a scenario where there is no known format in 
>the first place, how does that impact the cost 
>of making burned-in accessibility? Is it easy to 
>transfer from format to format, as the video 
>encoding is? If we don't mandate some format, 
>then how many do we expect to have to provide?

I'm sorry, I don't get the question.  Maybe you 
are saying that if accessibility is burned in, 
and so I have to provide variants for each 
accessibility axis, and I also have to provide 
variants for each platform because there is no 
mandated format, then the two multiply.  Yes, 
this is true.

This can be alleviated by having adaptable 
content, and I am aware of the need for a content 
format, as previously discussed.
-- 
David Singer
Apple/QuickTime

Received on Wednesday, 4 July 2007 15:05:37 UTC