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

Re: [media] Moving forward with captions / subtitles

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 15 Feb 2010 09:04:50 +1100
Message-ID: <2c0e02831002141404y61bf05f3qfce00a74e18ae430@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Eric Carlson <eric.carlson@apple.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
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 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.


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

Cheers,
Silvia.
Received on Sunday, 14 February 2010 22:05:43 GMT

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