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: Fri, 19 Feb 2010 11:45:03 +1100
Message-ID: <2c0e02831002181645k7e95e674s89e8de4a7dcc6583@mail.gmail.com>
To: David Singer <singer@apple.com>
Cc: philipj@opera.com, Eric Carlson <eric.carlson@apple.com>, Geoff Freed <geoff_freed@wgbh.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Fri, Feb 19, 2010 at 10:24 AM, David Singer <singer@apple.com> wrote:
> On Feb 17, 2010, at 22:42 , Silvia Pfeiffer wrote:
>> On Thu, Feb 18, 2010 at 4:49 PM,  <philipj@opera.com> wrote:
>>> On Thu, 18 Feb 2010 00:31:17 +0800, Eric Carlson <eric.carlson@apple.com>
>>>>  +  I assume that if I use our track API to examine the track tracks in a
>>>> trackgroup, the one chosen from among a group of alternates is enabled, and
>>>> the others are not?
>>> What does enabled mean here? Since the MediaTracks API doesn't reflects
>>> the concept of groups, the mapping is open for debate. I think we should
>>> either reflect groups in some way, or we should simply expose all tracks
>>> in all groups (enabled or not) and setting .enabled=true on a track should
>>> implicitly disable the others in the same group.
>> I think Eric has already considered using this API for both, tracks
>> embedded and external to the media resource. Also, in MPEG there is
>> the construct of groups, too. So maybe we need to introduce that in
>> the API somehow?
>>>>  + Do we enable the first track in a group if none match?
>>> I don't think so, but we haven't discussed the track selection algorithm
>>> much at all. I suppose it should first find the the first track with the
>>> enabled="" attribute in each group and enable that. But do we also want an
>>> enabled attribute on the group itself that performs selection based on
>>> media type, language, role etc?
>> No, I think we should refrain from that. The trackgroup has no
>> semantic meaning other than grouping tracks together to be activated
>> mutually exclusively. It's like a radio group. Using type, language or
>> role on the trackgroup is just a simplified way or expressing that all
>> track elements share the same value on those attributes, IMO. For
>> example, @track and @role could both be on the trackgroup element and
>> the the tracks inside don't have to all repeat it.
>>>>  + I think that a media query that evaluates to "false" means it *must*
>>>> not be enabled because it is not appropriate for the user's environment, so
>>>> should setting enabled to true on such a track just fail?
>>> I agree, possibly throwing NOT_SUPPORTED_ERR or some other exception.
>> Ok, added.
> It seems to be that if a trackgroup represents an optional feature (e.g. "captions"), then
> a) the expression that says whether the trackgroup as a whole is wanted or not, should be, well, at the trackgroup level (a media query)
> b) *which* of the trackgroup you want should be expressed by attributes on the enclosed tracks.
> Do we need something at the trackgroup level that gives me a clue what criteria to use to select between the tracks?  ("These differ by language", "These differ by mime type") or do we have a rule that is like <source> ... walk down the group and enable the first that seems supportable (and implicitly disable the rest)?  I am kinda not keen on 'best match' specifications (but they are hard to avoid when talking about languages).

Think of the trackgroup being the same as grouping tracks inside an
MP4 or QuickTime file: it has no other meaning than "these tracks are
mutually exclusive". There is no indication for the reason why this
trackgroup is grouped together and there probably shouldn't because we
may want different tracks being alternates for different reasons that
are not easily marked up.

With this background, I don't think there is a need to specify whether
the trackgroup is wanted as a whole. If one of the tracks is set to
enabled, then the trackgroup is wanted. If none is set to enabled,
then it is not.

Also, if the trackgroup has an attribute such as role="subtitle" and
none of the tracks overwrite this attribute with their own @role
attribute, it can be assumed that the distinction between the tracks
is that they are different subtitle tracks.

As for enabling tracks: the tracks in a trackgroup are not fundamental
different to the tracks outside a trackgroup:

* If there is a @enable attribute, the track is enabled - if there
isn't it's not.
-> in a trackgroup only the first such track is enabled

* If the track matches browser preferences (e.g. auto-enable all
tracks with role "caption" and lang "en") then the track is
auto-enabled by the browser.
-> only the first such track in a trackgroup is enabled

* Further the track can be enabled through a javascript call like:
video.tracks[1].enabled = true;
-> if such a track is part of a trackgroup, this will disable any
other enabled track in that trackgroup

I might add this to the wiki actually.

Received on Friday, 19 February 2010 00:45:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:09 UTC