[whatwg] Video, Closed Captions, and Audio Description Tracks

[Dave Singer]

At 0:25  +0100 10/10/07, Ivo Emanuel Gonçalves wrote:
>On 10/9/07, Dave Singer <singer at apple.com> wrote:
>>  If the delivery is streaming, or in some other way where the
>>  selection of tracks can be done prior to transport, then there isn't
>>  a bandwidth hit at all, of course.  Then the "ask this resource to
>>  present itself in the captioned fashion" is a reasonable way to do
>>  this.
>>
>>  Alternatively, as you say, one might prefer a whole separate file
>>  "select this file if captions are desired".
>
>The way I see it, the browser is working like a video player.  Modern
>video players allow users to configure if they would like to see the
>first subtitles track by default or not.  And if the user wishes to
>turn subtitles on, off, or switch to another subtitles track (e.g.
>another language) s/he right clicks the video screen and modifies the
>subtitles options.  Not elegant, but it works.

Yes, I wish it were this simple, but 
unfortunately, this doesn't cut it, in two 
respects.  (a) Users needing accessibility go 
crazy if they have to turn it on, resource by 
resource, by hand.  (b) Users needing some kinds 
of accessibility (e.g. visual assistance) have 
trouble with things like "right-click and choose 
a menu".

I don't think it's unreasonable to expect to use 
persistent preferences, if the spec. stays out of 
the field of trying to guess what all the axes 
(possibilities) are.  We've previously talked 
about
captions
high-contrast video
audio description of video
high-contrast (clarity) audio

and then the iPlayer comes along and has 'sign 
language' as another axis, which confirms that we 
can't think of all the axes up front.
-- 
David Singer
Apple/QuickTime