At 0:25 +0100 10/10/07, Ivo Emanuel Gonçalves wrote:
On 10/9/07, Dave Singer <[EMAIL PROTECTED]> 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
