Re: Acessibility of <audio> and <video>

At 11:17  +0300 4/09/08, Henri Sivonen wrote:
>On Sep 4, 2008, at 01:13, Dave Singer wrote:
>
>>2.1.2 Configuring
>>Sometimes, similarly, the media format itself can carry optional 
>>features. An example might be the 3GPP file format (or any file 
>>format from that family, such as MP4) with a text track in 3GPP 
>>Timed Text format. Enabling this track (and thereby causing it to 
>>be presented) may be a way to satisfy a need within a single media 
>>file.
>
>It seems to me that for captioning, an off-by-default track within 
>the main file is preferable over burned-in open captions, because 
>tracks within the main file travel better, compress better (and 
>transferring the captions even when not needed is not burdensome in 
>terms of relative network bandwidth) and make video more searchable.

All agreed, but if all you have is a couple of videotapes, one of 
which has burned-in captions, you might not have a choice.  We need 
to decide if open captions qualify as captions.

>>2.2.3 longdesc
>>The longdesc attribute, when used, takes a URI as value, and links 
>>to a 'long description'. It is probably the attribute to use to 
>>link to such things as a transcript (though a transcript is more of 
>>a fulltext alternative than a description).
>
>I think transcripts should not be considered accessibility-only 
>data. Transcripts are useful to users who can hear just fine. I 
>think an automated association mechanism isn't necessary here. <a 
>href='transcript.html'>Transcript</a> should do.

I don't see alt or longdesc as exclusive to accessibility.  But I am 
not wedded to them;  I just wanted to explore the case of 
out-of-media accessibility assistance.

>>    2. Subtitles (in the USA and Canada sense) are not strictly an 
>>accessibility issue, but can probably be handled here.
>
>>Note that since it's not possible to express a concrete 
>>anti-preference ('I absolutely must avoid captions'), all 
>>accessibility axes have to be expressed in terms of something 
>>positively needed ('I need video that avoids inducing epileptic 
>>fits') rather than avoided (you cannot say 'I must not be presented 
>>with video that might induce epileptic fits').
>
>I would caution against treating subtitles (in the US/Canada sense) 
>an instance of the same selection mechanism engineering problem as 
>captions (in the US/Canada sense) just because they are the same 
>engineering problem as far as encoding timed text goes.

Yes, your points are well taken.  It may well be that we should be 
silent about sub-titles (or say it's a separate problem that should 
be controlled somehow else) and focus on classic captions.  We may 
need DOM methods to handle tracks in a media resource (e.g. 
enable/disable them by ID or name etc.) -- then a javascript at the 
HTML level could be written behind buttons offering "turn on 
sub-titles when the actor is speaking classical Latin" or whatever is 
appropriate for the resource (and the page author could know).

I very carefully wrote the proposal in 'positive' terms (I like 
captions) rather than negative ("I'm deaf"), precisely because there 
are plenty of circumstances where people like captions;  they are 
often on in cars, with the audio turned way down, for example.

>More to the point even, automatic mechanisms for language selection 
>are known to be *practically pointless* to engineer, because we 
>already know from HTTP Content-Negotiation that users don't bother 
>to configure it.

We've had some success with QuickTime and alternate language, on occasion.


-- 
David Singer
Apple/QuickTime

Received on Tuesday, 9 September 2008 22:31:41 UTC