Re: Is longdesc a good solution? (was: Acessibility of <audio> and <video>)

yes and yes.  Why do I have to be told to do something I might not be able 
to do.  I don't have a sound card so it may not even help then.

----- Original Message ----- 
From: "Henri Sivonen" <hsivonen@iki.fi>
To: "Matt Morgan-May" <mattmay@adobe.com>
Cc: "Leif Halvard Silli" <lhs@malform.no>; "HTML WG" <public-html@w3.org>; 
"W3C WAI-XTECH" <wai-xtech@w3.org>
Sent: Tuesday, September 09, 2008 5:36 AM
Subject: Re: Is longdesc a good solution? (was: Acessibility of <audio> and 
<video>)



On Sep 9, 2008, at 00:26, Matt Morgan-May wrote:
If I have to go hunting for it or don't know it is there, I will miss the 
transcript.  What I need is not to be presented with an opportunity to fail 
in the first place by clicking something I cannot use but instead, be 
presented with the appropriate context for my platform perhaps configurable 
through my browser.

> On 9/8/08 1:22 AM, "Henri Sivonen" <hsivonen@iki.fi> wrote:
>> On Sep 7, 2008, at 22:31, Leif Halvard Silli wrote:
>>
>>> <video>: Would you propose the use of <object> instead of <video>
>>> when HTML fallback for videos is wanted as well?
>>
>> No. I would propose that users who don't see the video track play the
>> video and listen to the soundtrack. When the content provider makes
>> an
>> additional effort for addressing the not seeing the video track case,
>> I'd suggest the effort be put into making an alternative audio
>> description sound track.
>
> Where's the opportunity cost assessment on this one, then?
>
> It is clearly less work to produce a text equivalent and associate
> it, than
> to script, voice and associate a secondary audio description track.

You are right. Even though I suggested merely listening to the sound
track in the common case, I went straight to the rather impractical
high end with the more accessible suggestion.

How far-fetched is audio description authoring in your assessment?
Does it even make sense to build browser support for it?

In any case, a full-text transcript (including annotations recounting
significant visual happenings) does not belong in <object> fallback,
which is what Leif asked me about, because a full-text transcript-- 
once written--is useful in general. In particular, it is useful in
cases where it is *also* useful to make <object> render the media file
(even if only for the audio for blind and low-vision users and only
for the video for deaf or low-hearing users). The transcript should be
available on the same page or on another page via a plain link.

> Which is partly why WCAG 2 Guideline 1.2 offers authors the
> choice of full-text transcript as an alternative, at level A.
>
> What you're proposing means that the fallback that's good enough for
> WCAG
> would need to be done as a hack in HTML5, rather than a clean semantic
> association.

Would this
<video src=movie.ogg>Please upgrade to a browser that supports HTML5
video.</video><p><a href=transcript.html>Annotated transcript</a></p>
be a "hack"?

Is a semantic association between the <video> element and the
transcript necessary if the link is very near the video in the
document reading order?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 9 September 2008 13:16:22 UTC