RE: [media] Moving forward with captions / subtitles

Comments preceded by GF.

________________________________________
From: public-html-a11y-request@w3.org [public-html-a11y-request@w3.org] On Behalf Of Silvia Pfeiffer [silviapfeiffer1@gmail.com]
Sent: Sunday, February 14, 2010 6:57 AM
To: Philip Jägenstedt
Cc: Eric Carlson; HTML Accessibility Task Force
Subject: Re: [media] Moving forward with captions / subtitles

On Sun, Feb 14, 2010 at 10:23 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Sun, 14 Feb 2010 17:22:23 +0800, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>>
>> On Sun, Feb 14, 2010 at 6:45 PM, Philip Jägenstedt <philipj@opera.com>
>> wrote:
>>
>> I wouldn't think the format is the issue here - @type is just a
>> description of what format to expect, not as a selection mechanism.
>> Just like in an img element there is also support for several file
>> formats, but there is no means to mark up selections between different
>> ones. Even if we support more than one format, that shouldn't become a
>> selection criterium.
>
> If type has no influence over what track is selected I suggest we not have
> the attribute at all.


It's already an attribute of the <source> element and necessary there,
so that's not possible. However, what is more important is that it is
an indication for how to parse the referenced resource. In particular
with srt we can include the charset that way without having to add an
additional attribute. It's a necessary decoding hint.


>>> Do we at all want to support the case of enabling multiple text tracks in
>>> a
>>> declarative way or via browser context menus? In my opinion this is a bit
>>> overkill (I've never used a media player that supports it) and we might
>>> delegate this to scripts. If others agree, we don't need any grouping
>>> element for the purpose of making a group of tracks mutually exclusive --
>>> all tracks are mutually exclusive.
>>
>> Did you mean all source elements within a track of a certain role are
>> mutually exclusive? If so, I agree.
>
> No, I mean that all tracks of any language/role/whatever are mutually
> exclusive. I've never seen a media player that allows enabling multiple text
> tracks simultaneously and wouldn't want to figure out a UI for doing it in
> the context menu or with native controls.

In my demo, I have up to four tracks active at the same time:
http://annodex.net/~silvia/itext/elephant_no_skin_v2.html
* captions
* subtitles
* chapter markers
* textual audio descriptions

As long as they are not displayed onto the same position on screen,
that's not a problem. Admittedly, in my demo, subtitles and captions
clash, so one wins out. But the others do not clash. So, I think
different roles can well be displayed in parallel.

GF:  I would prefer that we allow multiple tracks to be active simultaneously, regardless of language or role.  There are already real use cases today where various combinations of subtitles, captions and audio descriptions are simultaneously active; production agencies in the US are offering multi-track accessibility as a service so we need to support this. 

Also, I wouldn't be so quick to say that all tracks of the same role should be mutually exclusive.  Most of the time, only one track per role *will* be all that is necessary.  However, there may be cases where, for example, someone will want to use a caption track and a subtitle track simultaneously in order to learn a new language.  Or have an audio track of descriptions running alongside directorial commentary.  

I don't know exactly what it would take to allow multiple roles to be active in this way, but we shouldn't abandon the idea so soon.  Tthe idea of having the author solve the problem through the use of scripts has been floated, but is that a good solution?  If the goal of <video> and related elements/attributes is to make it easier for authors to integrate multimedia-- and *accessible* multimedia, at that-- into the Web, does pushing multi-track-role capability to scripts contribute to that goal?




>>> The other kind of grouping is per role (subtitles/captions/karaoke),
>>> language and... something else? If this is given by role="" and lang="",
>>> how
>>> should a context menu be constructed? Group by role or by language?
>>
>> To me - just from a menu construction POV - it seemed to make more
>> sense to group by role and within role as alternatives.
>>
>> The idea of grouping per language seems to me to make things more
>> complicated.
>
> No grouping at all makes it even simpler :)

Actually, no. When I tried that in
http://annodex.net/~silvia/itext/elephant_no_skin.html it gave me all
sorts of headaches. And the first feedback I got on that demo was: why
is it so talkative and why aren't you grouping things that are
alternatives together.



>> I think with the tracks that are grouped by "role" we get exactly this
>> behaviour. The distinction between them is based on lang, type and
>> media query, so fits very well with this description of "alternate
>> group".
>
> No matter how we group it the tracks will be the same and the information
> about the tracks available from the markup will be the same.

Indeed, but if we don't group the parsing code gets a lot harder and
it's much harder to decide which are alternatives to each other and
which additional.


> I don't think
> that grouping should have any influence on track selection. Grouping is only
> relevant if we want to:
>
> * declaratively enable multiple text tracks simultaneously (in markup), or
> via native browser UI

As stated above, I indeed believe this is necessary. In particular if
we want to support textual audio descriptions through srt files.

GF:  Agreed.


> * provide some nesting in context menus

These can be created through parsing, too, but are much harder to create.


> I don't think either of these are important enough to introduce new elements
> or attributes.
>
> Am I missing something?

I think so - see above. :-)


Cheers,
Silvia.

Received on Sunday, 14 February 2010 13:19:44 UTC