Re: Acessibility of <audio> and <video>

On Aug 25, 2008, at 7:40 PM, Leif Halvard Silli wrote:

>
> Anne van Kesteren 2008-08-25 17.34:
>
>> On Mon, 25 Aug 2008 17:19:43 +0200, Edward O'Connor  
>> <hober0@gmail.com> wrote:
>>> This is because, for legacy reasons, <img> is an empty element,  
>>> and so
>>> its text equivalent lives in an attribute, whereas <audio> and  
>>> <video>
>>> both support rich fallback via their content.
>> Actually, I think the idea is that the content stream itself is  
>> accessible. The contents of the <audio> and <video> element are a)  
>> for <source> elements and b) for user agents not supporting <audio>  
>> and <video>.
>
>
> You are right: Edward O'Connor is wrong. <video>/<audio> directly  
> rule out (mis)using its fallback capabilities for fallback:
>
> " User agents should not show this content to the user; it is  
> intended for older Web browsers which do not support video, so that  
> legacy video plugins can be tried, or to show text to the users of  
> these older browser informing them of how to access the video  
> contents."

Which certainly goes against our universality design principle. I  
think at the very least, HTML5 should be expected to provide  
mechanisms for authors to achieve universality. The canned UA fallback  
informing users how to access the video contents could be the final  
fallback if the author provides nothing. Another common use case might  
be for users to avoid bandwidth hungry video, but still want a  
fallback image representative of the video. The user shouldn't be  
forced to download the entire video just to get that image, That would  
override the users desires to get stills but not full motion video due  
to bandwidth constraints.

Take care,
Rob

Received on Monday, 25 August 2008 18:13:14 UTC