Re: Fwd: Progress on video accessibility

Hi Leif,

On Sat, Aug 1, 2009 at 12:08 AM, Leif Halvard Silli<> wrote:
> 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!

Excellent! :-)

> 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.

The idea is that those elements - just like the default video controls
- will be default displays that the browser provides. I do not
understand how accessibility for the default video controls works, but
these would work in the same way.

Right now, all I was able to do was to create controls and text
displays in the DOM through javascript. I am not sure that it should
be exposed in the DOM or just accessible through a javascript API.

> 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/" >
>    </sub>
>    <tad><!-- '<itext category=TAD' in your code -->
>      <source id="audiodesc" lang="en"
>       charset="ISO-8859" display="yes"
>       src="subtitles/" >
>    </tad>
>    <cue><!-- '<itext category=CUE' in your code -->
>      <source id="chapters" lang="en"
>       charset="ISO-8859" display="yes"
>       src="subtitles/" >
>    </cue>
>  </itext>
> </video>
> 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

Indeed that is one of the experiences that I had during the authoring
of this demo, too, and it is indeed in my list of feedback in the wiki
page at
. My proposal is, however, for a list element that structures the text

I would propose to keep a generic element for structuring rather
than<tad>, <cue>, and <sub> simply because it can be used for any type
of time-aligned text category rather than restrict ourselves to the
ones we now know about. It is my experience that they all share the
same basic features: namely providing time-aligned text for the video,
and therefore can all be dealt with in the same generic way. What
needs to be specific, though, is their default CSS styling.

> 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.)

There is an advantage for specifying the language in the html code: it
tells the browser immediately what language alternatives are
available. Thus, this enables us to build the menu that I have under
the "text" button in the video player.

As for the charset - I put it into the html code to have access to
that information. If that is better done by naming convention of files
on the server, then I'm happy to remove the attribute. I must admit
though that I have no idea how common your proposed naming convention
solution is. Does only apache provide it? Is it something that all Web
servers are required to do or do by de facto standardisation? I'd be
perfectly happy for it to work this way.

Best Regards,

Received on Saturday, 1 August 2009 11:39:25 UTC