This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12141 - <video> Specifically state that all <track> options be exposed to the end user
Summary: <video> Specifically state that all <track> options be exposed to the end user
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11ytf, media
Depends on:
Blocks:
 
Reported: 2011-02-19 20:10 UTC by John Foliot
Modified: 2011-08-11 23:53 UTC (History)
12 users (show)

See Also:


Attachments

Description John Foliot 2011-02-19 20:10:22 UTC
Situation: a <video> element might have 2 <track elements each claiming to be @kind=caption @srclang=EN. The spec should explicitly state that both caption options be presented to the end user, as the authors and content of either caption file might differ.
Comment 1 Philip J├Ągenstedt 2011-02-20 16:22:35 UTC
Agree, although this is already the case in my reading, making it more explicit would be good, as at least Silvia and John have found the situation to be less than crystal clear.
Comment 2 Martin Kliehm 2011-02-22 16:12:56 UTC
The HTML accessibility bug triage sub-team thinks this issue should be task force priority because it's related to the other media work, adding the a11yTF keyword.
Comment 3 David Singer 2011-02-22 17:56:08 UTC
I am not sure I agree completely.  The example given is a clear case, but what if (hypothetically) the UA knows it is audio-only (e.g. for a non-sighted user) and there are sign-language tracks? Why offer them to the end-user at all?

Some kind of UA discretion should still be allowed.
Comment 4 Philip J├Ągenstedt 2011-02-22 19:24:27 UTC
Perhaps I've misunderstood, I read John's example as meaning that "duplicate tracks" (same kind/src/label, which is invalid per the spec) should still be exposed by the UA.
Comment 5 John Foliot 2011-02-22 19:31:28 UTC
(In reply to comment #3)
> I am not sure I agree completely.  The example given is a clear case, but what
> if (hypothetically) the UA knows it is audio-only (e.g. for a non-sighted user)
> and there are sign-language tracks? Why offer them to the end-user at all?
> 
> Some kind of UA discretion should still be allowed.

How would the UA know whether a non-sighted user would want access to the
sign-language tracks or not? I feel it is a slippery slope when we presume to
know what any given user 'wants'. 

If UA's wish to offer a filtering mechanism, then that is a feature of that UA - however the default should still be as suggested and filtering be a user-option. (I've long adhered to the axiom 'author proposes, user disposes'.)
Comment 6 Silvia Pfeiffer 2011-02-23 00:37:52 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > I am not sure I agree completely.  The example given is a clear case, but what
> > if (hypothetically) the UA knows it is audio-only (e.g. for a non-sighted user)
> > and there are sign-language tracks? Why offer them to the end-user at all?
> > 
> > Some kind of UA discretion should still be allowed.
> 
> How would the UA know whether a non-sighted user would want access to the
> sign-language tracks or not? I feel it is a slippery slope when we presume to
> know what any given user 'wants'. 
> 
> If UA's wish to offer a filtering mechanism, then that is a feature of that UA
> - however the default should still be as suggested and filtering be a
> user-option. (I've long adhered to the axiom 'author proposes, user disposes'.)


I guess the comment that Dave makes is that the UA should have the possibility to decide what tracks to expose to a user through a track menu that is automatically displayed as part of the video controls.

I am further assuming that the idea is that if a user has set their preferences to be to not see any video tracks (e.g. because they are blind or have their eyes elsewhere) and therefore prefer to always activate the first appropriate audio descriptions track (being appropriate because it's in their preferred language) then the UA should not display these unwanted tracks in the track selection menu.

I am further assuming that the idea is that this would remove complexity from the user and simplify their choices - in particular where there is little real estate as on a mobile device.

(Dave, correct me if I am falsely assuming your line of thought.)

I actually think that this should be a user preference setting, too - or something that the browsers implement dependent on the available real estate and user preferences. But as a default, I agree with John that all of the available tracks should be displayed.
Comment 7 David Singer 2011-02-24 01:34:14 UTC
Yes, I just want to be wary of saying UAs 'must' not exercise discretion and 'must' present every option to the user.  'Should' perhaps, but not 'must'.  (how on earth would I present a sign-language option on a braille device?).
Comment 8 Silvia Pfeiffer 2011-02-24 02:07:40 UTC
(In reply to comment #7)
> Yes, I just want to be wary of saying UAs 'must' not exercise discretion and
> 'must' present every option to the user.  'Should' perhaps, but not 'must'. 
> (how on earth would I present a sign-language option on a braille device?).

I would say that the tracks have to be exposed in the JavaScript API. As for what goes into the default menu on screen, that is something that should be left to the browsers to decide on how it makes sense IMHO.
Comment 9 David Singer 2011-05-05 17:17:47 UTC
(In reply to comment #8)
 
> I would say that the tracks have to be exposed in the JavaScript API. As for
> what goes into the default menu on screen, that is something that should be
> left to the browsers to decide on how it makes sense IMHO.

Exposed to the scripts etc., absolutely.  'Exposed to the user' assumes a UA design in which the user gets menus of interactive choices, assumes that all choices (relevant or not) must be exposed in those menus, and so on.
Comment 10 Frank Olivier 2011-05-05 18:51:10 UTC
> Exposed to the scripts etc., absolutely.  'Exposed to the user' assumes a UA
> design in which the user gets menus of interactive choices, assumes that all
> choices (relevant or not) must be exposed in those menus, and so on.

Agree. Scripting - yes. Specifying how the user agent user experience should look and behave down to this level of detail is overly restrictive, given the variety of current and future user agents.
Comment 11 Ian 'Hixie' Hickson 2011-06-03 00:29:34 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: I don't understand. Is this asking about UI requirements or about API requirements? If there is a confusion here, could someone who is confused let me know what is misleading them? I'm happy to fix the spec, I just don't get what's wrong here.
Comment 12 Silvia Pfeiffer 2011-06-03 01:41:54 UTC
We refer to this statement:
"there must not be two track element children of the same media element whose kind attributes are in the same state, whose srclang attributes are both missing or have values that represent the same language, and whose label attributes are again both missing or both have the same value."

Comment_4 is the key comment.

It was unclear to John and me what happens with an invalid specification of several tracks of the same kind/src/label combination.

The issue is that dealing with the invalid case doesn't really need to be in the spec, but that it would still be nice if all browsers behaved the same in such an invalid situation and not dropped any tracks on the floor. In particular, they need to remain available in the media element's TextTrack[] list.

Might be worth a small comment. Though if that's clear to browser developers, it's ok to have clarified this understanding for Web developers.
Comment 13 John Foliot 2011-06-03 12:39:30 UTC
(In reply to comment #12)u
> 
> The issue is that dealing with the invalid case doesn't really need to be in
> the spec, but that it would still be nice if all browsers behaved the same in
> such an invalid situation and not dropped any tracks on the floor. 

Actually, I thought that prescribed error handling was in scope. While this is certainly not conformant code, it could exist in the wild, and if that is the case a specific default of showing both options should be the expectation.

> In
> particular, they need to remain available in the media element's TextTrack[]
> list.

+1

> 
> Might be worth a small comment. Though if that's clear to browser developers,
> it's ok to have clarified this understanding for Web developers.

I'm not sure that it is clear, and so specificity here would be an improvement.
Comment 14 Michael[tm] Smith 2011-08-04 05:04:29 UTC
mass-moved component to LC1
Comment 15 Ian 'Hixie' Hickson 2011-08-11 20:40:33 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: see diff given below
Rationale:

(In reply to comment #12)
> We refer to this statement:
> "there must not be two track element children of the same media element whose
> kind attributes are in the same state, whose srclang attributes are both
> missing or have values that represent the same language, and whose label
> attributes are again both missing or both have the same value."

This statement says _nothing_ about consumers, user interface, or anything relating to how the browser is supposed to act.

I've added some text to the specification that reemphasises this point generally, as it seems to be a point of common confusion. I haven't added any text specifically about text tracks because there is nothing special about text tracks here as opposed to any other feature.

The spec doesn't define user interface. A browser could be completely conforming if it never exposed any of the tracks to the user and just automatically picked one. Or two. Or displayed all of them simultaneously, or none ever, or had a menu permanently on the screen that allowed the user to enable or disable them, or handled duplicates by always enabling or disabling them together, or called them "duplicate one" and "duplicate two" in the user interface, or downloaded the files and examined them carefully and then used AI or the Amazon Mechanical Turk to create clear distinguishing titles or printed the complete text of both text tracks and then required the user to highlight which cues the user wanted from each text track and then had the user scan the tracks back in and then enabled and disabled the tracks according to the user's indicated preference.

If there are specific requirements on user interfaces that you think are important for user agents to implement to be accessible to a broad audience, then that is the kind of thing to put in a UAAG document or to address directly to the user agent vendors.
Comment 16 contributor 2011-08-11 20:40:51 UTC
Checked in as WHATWG revision r6419.
Check-in comment: This seems to be a common mistake, so let's call it out.
http://html5.org/tools/web-apps-tracker?from=6418&to=6419
Comment 17 Silvia Pfeiffer 2011-08-11 23:53:26 UTC
(In reply to comment #15)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Partially Accepted
> Change Description: see diff given below
> Rationale:
> 
> (In reply to comment #12)
> > We refer to this statement:
> > "there must not be two track element children of the same media element whose
> > kind attributes are in the same state, whose srclang attributes are both
> > missing or have values that represent the same language, and whose label
> > attributes are again both missing or both have the same value."
> 
> This statement says _nothing_ about consumers, user interface, or anything
> relating to how the browser is supposed to act.
> 
> I've added some text to the specification that reemphasises this point
> generally, as it seems to be a point of common confusion. I haven't added any
> text specifically about text tracks because there is nothing special about text
> tracks here as opposed to any other feature.
> 
> The spec doesn't define user interface. A browser could be completely
> conforming if it never exposed any of the tracks to the user and just
> automatically picked one. Or two. Or displayed all of them simultaneously, or
> none ever, or had a menu permanently on the screen that allowed the user to
> enable or disable them, or handled duplicates by always enabling or disabling
> them together, or called them "duplicate one" and "duplicate two" in the user
> interface, or downloaded the files and examined them carefully and then used AI
> or the Amazon Mechanical Turk to create clear distinguishing titles or printed
> the complete text of both text tracks and then required the user to highlight
> which cues the user wanted from each text track and then had the user scan the
> tracks back in and then enabled and disabled the tracks according to the user's
> indicated preference.
> 
> If there are specific requirements on user interfaces that you think are
> important for user agents to implement to be accessible to a broad audience,
> then that is the kind of thing to put in a UAAG document or to address directly
> to the user agent vendors.

OK, just to clarify what it means for this particular case: it means that the parsing rules require parsing all available tracks and thus they end up in the JavaScript API, even if the producer does not adhere to the requirements.

I am fine with this explanation.