[whatwg] Thoughts on video accessibility

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

Received on Tuesday, 9 December 2008 11:59:12 UTC