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.

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.

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.

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.

(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'.)

(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.

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

(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.

(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.

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

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.

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.

(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.

mass-moved component to LC1

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.

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

(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.