Re: Acessibility of <audio> and <video>

Hi Lachlan,

On Sep 2, 2008, at 12:36 AM, Lachlan Hunt wrote:

>
> Leif Halvard Silli wrote:
>> Justin James 2008-09-01 19.42:
>>> I can imagine the furor if we also applied this logic to
>>> images, by saying, "if you want accessible images, use a format
>>> that natively supports metadata of alternate text, or put a
>>> subtitle/caption/legend/etc. in your image."
>
> No. Unlike video, images have no way embedding accessibility  
> features within them, and their meaning is very often depending on  
> the context. However, videos do have various ways of including  
> native accessibility features, such as subtitles/captions or audio  
> descriptions.

Actually, that's not the case. As we have already proposed, still  
images also have mechanisms to provide text equivalents and other  
author provided metadata just as video and audio do.[1][2]

>> Add to that that movie formats are *very* often used for displaying  
>> photos.
>
> Could you elaborate on what you mean, provide some sort of evidence  
> to support this claim, and also explain why it's relevant?
>
>> Plus the fact the <video> elment itself has a poster image to be  
>> displayed before the video is started.
>
> I'm not sure why that is relevant.  The poster frame can be thought  
> of as being more like an icon representing the video.  It's the  
> content of the video that is important

This is relevant since a disabled user (or even other users) may elect  
not to retrieve video formats due to low bandwidth connections, or  
inability to consume what is often inaccessible content. The poster  
image may be all their UA retrieves (if that), but if there is no  
mechanism to provide fallback for the poster image, then the user gets  
no fallback.

>> instead allow textuall fallback <element>inside the element</>,  
>> then that would be better.
>
> OK, let's look at the various kind of alternatives that could be  
> potentially provided for people who either can't watch or don't want  
> to watch the video.
>
> * Transcript of spoken content.
> * Textual descriptions of relavant non-spoken content.
>  e.g. descriptions of significant actions or sounds in the video.
> * Still images illustrating significant moments from the video.
>  e.g. images of presentation slides, if the video was of someone  
> giving
>  a presentation.
> * A link to download the video, possibly in alternative formats, to
>  watch in an external media player, perhaps in several formats.
> * Video embedded in the page using an alternative method
>  e.g. Flash, the Cortado Theora applet, or whatever
>
> Any or all of those could be provided and all of them would be  
> suitable for people in the following categories:
>
> 1. People using browsers that don't support <video>
> 2. People using browsers that do support video, but don't support the
>   codecs used.
> 3. People who can't see the video well (blind or visually impaired)
> 4. People who can't hear the video well (hearing impared or no
>   headphones/speakers available)
> 5. People who want to search the content of the video
>   e.g. Instead of seeking through the video to find the information
>   they want, just look through the transcript, from which they can  
> also
>   copy quotes if they want.
>
> Given that the alternative content is useful to so many people,  
> regardless of physical disability or technological limitations, it  
> makes  sense for it to be provided in a way that makes it available  
> to everyone.  This is one reason why hiding alternative content away  
> within the video element is not helpful because it only makes it  
> readily available to a small subset of those people who might want  
> or need it.

You shouldn't think of the contents of the video element as "hidden  
away". Fallback is another part of the rich document data that HTML  
facilitates. There are all sorts of ways UAs can make it available to  
all users[3][4]. Some WG members feel we shouldn't specify that UAs  
present document data[5], but even if we don't specify it, we  
shouldn't assume UAs will be brain dead about it presenting it (even  
if they have been historically).

> Another reason to consider is that we know very well what authors do  
> when they are encouraged to hide alternative content specifically  
> for accessibility within elements.

We certainly do not want to encourage authors to "hide alternative  
content". Rather we want to provide mechanisms for authors to include  
text equivalents within their documents. Will these mechanisms be  
misused and abused? Certainly. However, that shouldn't stop us from  
providing those mechanisms.

>  For example:
>
> <noframes>Your browser does not support frames, Please upgrade to
> Netscape 4</noframes>
>
> <noscript>Sorry, your browser doesn't support javascript.</noscript>
>
> <object ...>Please install flash</object>

Yes these are all good examples of poor practice. We should make it  
clear that such things are misuses of these mechanisms.

> It might work ok for <video> during the transitional period when not  
> all
> browsers implement it, since authors will gain practical benefits by
> including alternative embedding mechanisms within the video element.  
> e.g.
>
> <video src="movie"><object data="movie"></object></video>
> <p><a href="movie">Download movie</a>
>   <a href="transcript">Read transcript</a> ...

These last two lines of source are really mechanisms UAs should  
provide where appropriate. For users using UAs where such mechanisms  
are appropriate, the UA should provide UI. For UAs where such  
mechanisms are inappropriate, then the the content is superfluous.

> But, in the long term, after browsers with native video support are  
> more
> widely used, we'll likely start seeing people leaving the video  
> element
> empty or including useless messages, and accessibility loses.   
> Whereas by encouraging people to use visible alternative content,  
> everybody wins.

Again, there are two problems with this point of view. First you  
assume fallback is necessarily invisible content. That's not a valid  
assumption. Second you're assertion that the misuse of accessibility  
mechanisms should lead us to drop such accessibility mechanisms. If  
you're correct and users will be able to count on accessibility  
features within the video and audio resources themselves, then the  
occasional times when the UA/user reaches this fallback of last resort  
its misuse will not really be a significant problem. When meaningful  
fallback is provided by the author, it will be the only way the user  
can consume the content.

Take care,
Rob

[1]: <http://esw.w3.org/topic/HTML/UANormAndDOMForMediaPropeties>
[2]: <http://www.w3.org/Bugs/Public/show_bug.cgi?id=5755>
[3]: <http://www.w3.org/Bugs/Public/show_bug.cgi?id=5756>
[4]: <http://esw.w3.org/topic/HTML/RicherUIAccessToHTMLData>
[5]: <http://www.w3.org/Bugs/Public/show_bug.cgi?id=5756#c3>

Received on Tuesday, 2 September 2008 07:59:48 UTC