W3C home > Mailing lists > Public > public-html-a11y@w3.org > February 2010

Re: [media] Moving forward with captions / subtitles

From: Philip Jägenstedt <philipj@opera.com>
Date: Mon, 15 Feb 2010 13:34:51 +0800
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Eric Carlson" <eric.carlson@apple.com>, "HTML Accessibility Task Force" <public-html-a11y@w3.org>
Message-ID: <op.u75lsdpmatwj1d@philip-pc>
On Mon, 15 Feb 2010 06:04:50 +0800, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Mon, Feb 15, 2010 at 1:44 AM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> On Sun, 14 Feb 2010 19:57:56 +0800, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>
>>> 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:
>>>>>
>>>>>> 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 assume the feedback was on the UI, not on the markup. I can't see the
>> markup is really necessary to achieve the wanted UI -- simply group all
>> tracks with the same role together. The markup itself can be organized  
>> into
>> groups by other means, e.g. putting all captions under <!-- captions -->
>
>
> No, not at all. The feedback was on having too much boilerplate and it
> being repeated between elements: every single <source> element would
> repeat the @role attribute. And grouping the same ones together would
> not be enforced, so readability is reduced. Plus you lack the
> possibility to specify when tracks with the same role are supposed to
> be alternatives.

I think we should optimize for the common case and that having any nesting  
when there are at most a few tracks (which should be the overwhelming  
majority of cases) makes the markup less clear. I could live with optional  
grouping, e.g. <trackgroup>:

Common case:

<video>
   <track src="captions.srt">
   <track src="zimu.srt" lang="zh">
</video>

Complex case:

<video>
   <trackgroup role="captions">
     <track src="captions.srt">
     <!-- lots of tracks -->
   </trackgroup>
   <trackgroup role="karaoke">
     <!-- lots of tracks -->
   </trackgroup>
   <!-- lots of groups -->
</video>

<track>s in a <trackgroup> are mutually exclusive while tracks in  
different groups are not. This is the only semantics expressed -- grouping  
doesn't have to be based on role. By default all tracks are mutually  
exclusive.

lang="" is already inherited, perhaps we could do the same for role="" to  
that either or both can be specified on <trackgroup>?

As long as native browser controls can find a suitable string for each  
track group, using the grouping in menus would be acceptable since usually  
there will be no groups at all and thus the common case doesn't suffer  
 from it.

Would this be an acceptable solution?

Note: there is no <source> element in this proposal, because there's no  
need for it.

>>>> 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.
>>
>> What's special about textual audio descriptions? Can you show an  
>> example of
>> an existing application (native or webapp) that allows enabling multiple
>> text tracks via menus and what it looks like? All I'm saying is that it
>> isn't necessary to provide the information of which tracks are supposed  
>> to
>> be mutually exclusive in markup -- it might still be po
>
>
> I've given you the link to the demo that I use at
> http://annodex.net/~silvia/itext/elephant_no_skin_v2.html as an
> example. You will need to go into the menu on the right of the video
> to activate a chapter track. It will then display on top of the video.
> To activate the audio description, you have to run a screenreader.
> Caption, chapter track and textual audio description run in parallel
> very nicely, since they do not overlap on the same screen space.
> Textual audio descriptions in fact are not displayed visually at all,
> but only aurally.
>
> You mention an alternative means of specifying mutual exclusivity.
> Please explain.

My suggestion was that all tracks be mutually exclusive, so the problem is  
rather how to enable several tracks simultaneously. If we cannot find an  
acceptable solution then this will have to be done by script.

>>>> 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. :-)
>>
>> We don't agree that role is the obvious axis along which tracks should  
>> be
>> grouped in the UI. There also doesn't seem to be agreement that all  
>> tracks
>> in a single role should be mutually exclusive. I think it should be  
>> possible
>> to activate several tracks, but only in browsers that can figure out  
>> what a
>> sensible UI for it should be, possible via a enabled="" attribute and
>> definitely via script. I still can't see that any grouping of the  
>> markup is
>> a good idea though, given that there are so many different axes along  
>> which
>> these groups could be made and none really make more sense than the  
>> other.
>> Personally I would be much more interested in language groups than role
>> groups because I immediately know which languages I'm interested in but  
>> can
>> live with either captions or subtitles.
>
> For every role, we specify a default css display style. This will
> enable the tracks of different roles to be displayed without
> infringing upon each other. I really don't see a need for script here,
> since it's much easier this way.
>
> If you do not group tracks, are tracks able to be active at the same
> time? I would definitely see a need to have multiple tracks active at
> the same time. For example, if I am both vision-impaired and
> hard-of-hearing, I would want both, the captions and the textual audio
> descriptions to be displayed on braille. Another example is when I
> watch a video of a foreign language and want to use the captions and
> my own language's subtitle track to be able to learn the language.
>
> If all tracks are mutually exclusive, how do you specify that some  
> aren't?

The answer for everything that isn't solved by markup and browser-native  
features is scripts. However a solution where grouping is optional and not  
based on roles would also be acceptable in my opinion.

-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Monday, 15 February 2010 05:35:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:02 GMT