[whatwg] Thoughts on video accessibility
Calogero Alex Baldacchino
alex.baldacchino at email.it
Tue Dec 9 11:59:12 PST 2008
Silvia Pfeiffer ha scritto:
> I heard some complaints about there not being any implementation of
> the suggestions I made.
>
> So here goes:
>
> 1. out-of-band
> There is an example of using srt with ogg in a out-of-band approach here:
> http://v2v.cc/~j/jquery.srt/
> You will need Firefox3.1 to play it.
> The syntax of what Jan implemented is different to what I proposed,
> but I wanted to take it forward and make it more generic.
>
> 2. in-band
> There is also a draft implementation of srt inside Ogg through the
> OggText specification, but I it's not released yet. It is also not as
> relevant to this group as the out-of-band example.
>
> Cheers,
> Silvia.
>
>
As far as I've understood from a first read of your proposal (I'm not
much inside that matter), current players/codecs implements different
kinds of bindings with text (either in-band or out-of-band) and supports
different formats, so perhaps there is place for both mechanisms you're
proposing:
- the html version, for compatibility with existing media and relative
external bindings, for servers not supporting the dynamic creation of
content defined by your ROE format and for people who don't want/can't
afford to modify the way their medias are served (e.g. they can't access
to the server where the media is stored and add or modify an xml
metadata file, but want to try and bind the media with some text they
can store separately);
- the xml file mainly to drive dynamic content creation, and as a
gradual replacement of other binding formats.
Any problem arising from the management of separate connections
(possibly to different domains) to get both the audio/video and the
textual resources, might perhaps be mitigated by indicating (or
establishing as default) a time to wait for external text before
starting the playback (in case the text resource fails to load -- e.g.
the server is temporarily offline -- and there is enough buffered
content to start playing before the browser gets any answer for any
other resource) -- when and if the text arrives, its use might be
skipped at all, or start by synchronizing with the current point in the
media; the same way, if any problem loading the text arose after
starting the playback, the missing parts might just be skipped (such
would be unlikely to happen if both the media and the text files were
located on the same server).
Perhaps, it might be useful to provied a way to indicate an alternative
media to stream, i.e. an .asx or .rm media which is internally binded
with only one of the supported languages, but the browser fails to bind
them with the 'primary' media, or in case the ROE format is not
supported (e.g. introduced in a "v2" of the spec), or the 'primary'
media is not supported by the browser, but the same content is available
in several formats (i.e. a lossless compressed version along a lossy
compressed one - the UA might even choice one basing on the network
capabilities) -- I know such is possible with source elements, but
perhaps some considerations are needed on the opportunity to relate
source element and text bindings, i.e. to tell the UA, by the mean of an
attribute, whether to verify if the source supports any of the declared
text resources, preferably one matching the locale, or not (that is,
specifying if a source is a 'last resort' in case the UA is unable to
bind any other source with the text -- other sources might be chosen
anyway, if no 'last resort' source is supported).
Anyway, the use of subtitles in conjunction with screen readers might be
problematic: a deeper synchronization with the media might be needed in
order to have the text read just during voice pauses, to describe a mute
scene, or to entirely substitute the sound, if the text provides a
translation for the speech (I guess such would be untrivial to do
without putting one's hands inside the media).
Everything, of course, IMHO.
Regards,
Alex
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
CAPODANNO A RIMINI HOTEL 2 STELLE
* 2 notti pernottamento con colazione a buffet euro 70,00, 3 notti euro 90,00
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8500&d=9-12
More information about the whatwg
mailing list