Re: Fwd: Progress on video accessibility

Silvia Pfeiffer On 09-07-31 09.16:

[ snip ]

> * The idea for the display of the text categories is that we use
> existing browser display capabilities to do the display. Thus, I have
> defined for each text category a default display mechanism, i.e. a div
> into which it gets rendered into the DOM and a default CSS styling for
> the div and the text inside it. This also enables a Web developer to
> make changes to the default display simply through their own CSS
> styling.

An exiting demo. And the automatic language selection also works!

On your demo page [1], you display for us some of the code - what 
you call "the main elements of this Web page". There, however, you 
do not list the DIV which displays the text. And the reason is of 
course that the DIV actually resides outside the VIDEO element - 
and that you only list the content of VIDEO. Is this how it is 
intended in the end?

It seems odd to keep text displayer element - the captions - 
outside VIDEO. And there is also no formal link in the form of 
e.g. a for="" attribute or similar, that links the DIV to the 
VIDEO. It seems to me that the text display element should be 
inside VIDEO or have a for="" attribute that links to the VIDEO 
element. A nested text display element would also be of advantage 
to get a logical CSS selector.

Why not something like this - as a rough sketch:

<video class="v" poster="elephant.png" >
   <source src="elephant.mp4" >
   <source src="elephant.ogv">
   <itext type="text/srt" display="auto" >
     <sub><!-- '<itext category=SUB' in your code -->
       <source id="video_af" lang="af" charset="ISO-8859"
        src="subtitles/" >
       <source id="video_el" lang="el" charset="ISO-8859-7"
        src="subtitles/" >
     <tad><!-- '<itext category=TAD' in your code -->
       <source id="audiodesc" lang="en"
        charset="ISO-8859" display="yes"
        src="subtitles/" >
     <cue><!-- '<itext category=CUE' in your code -->
       <source id="chapters" lang="en"
        charset="ISO-8859" display="yes"
        src="subtitles/" >

Then, supposedly, the <itext> container could be used as "canvas" 
for the captions? And with a for="" attribute, it could also be 
placed outside the VIDEO, AUDIO, OBJECT etc - if that is an advantage.

The ideas was also to make the SOURCE elements of ITEXT inherit 
all inheriatble values from the parent element. And to make ITEXT 
more like VIDEO.

Btw, the language of e.g. the srt files could have been derived 
from HTTP if the files e.g. had a language extension - Apache 
would usually interpret '' as a English resourcs. 
And ditto with regard to the encoding - '' 
would usually be delivered by Apache as a resource in UTF-8 encoding.

Are there advantages to using @lang and @charset instead? In 
theory, if using extensions, you would not need more than /one/ 
<source> element for the SUB category, as you could do

	<source src="text">

and then those with a UA set to prefer e.g. Greek, would actually 
be delivered "". But may be using HTTP content negotiation 
would be less use configurable? (I saw, at least in Webkit, that 
there were a menu for choosing the captioning language.)

leif halvard silli

Received on Friday, 31 July 2009 14:08:56 UTC