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

If a manuscript is available, I don't see the need for a transcript which to 
me seems redundant.

Barring this, I am not certain that *@longdesc* is appropriate for either 
since replacement/substitution is not *description*.  I fear we vear from 
the value of @longdesc if we use it in a manner which provides substitution. 
an @longdesc of a video would be something achin to textual audio 
description.  A transcript or a manuscript is the full text or in the case 
of a transcript, perhaps an annotated full text of what is said in the 
<video> which provide proper substitution.  In any case, even what is in the 
@longdesc in this case is replacement and description probably needs to 
confine its self to describing the activity and the surroundings etcettera 
without including the content.  We'd get the names of the characters, the 
colors and sizes, what they are dressed like, where the event is being held 
etc.

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



Henri Sivonen 2008-09-09 11.36:

> On Sep 9, 2008, at 00:26, Matt Morgan-May wrote:
>> 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.

Those hindered from listening would need the transcript most.

>> 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?

As interesting as the answer to that question indeed is, it is
also a question very much colored by the (commercial) meaning of
the word "video". A <video> doesn't necessarily contain a video.
It can just be a recording of a speech, for instance.

About speech: If <video> and/or <object> represents a streaming of
a live event, then sometimes the manuscript will be made available
in the same moment the speech is being held.  After the speech,
what would the government publish on its web site for "common
consumption"? The speech manuscript or the speech transcript?

It could make sense to offer the manuscript for public consumtion,
and the transcript as fallback for the video. If transcript was
unavailable, it could also make sense to offer as fallback a link
- in the form of a @longdesc URI for instance - to the manuscript.
  And I don't think that there will always be natural to place a
link to the manuscript close to the <video>.

> 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.


* What if clicking the "plain link" could "open" the fallback of
the <object> for regular users? Why must <object> be so closed? Or
perhaps I should say: Why must <video> be so closed?
* What if the AT user would like to listen to the
transcript/manuscript being read by the familiar voice of the
software instead of listening to the (unclear) voice from a live
recording?

Making the manus/transcript available via @longesc doesn't prevent
  it from being referenced in the juxtaposing text either.


>> 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?

A problem is that it might not be "very near" the video. E.g. if
the fallback was a manuscript (since transcripts are hard work),
then the author might not see a reason to place a link to the
transcript  near the <video> if the link was provided elsewhere.
-- 
leif halvard silli

Received on Tuesday, 9 September 2008 15:56:43 UTC