W3C home > Mailing lists > Public > public-html-a11y@w3.org > August 2011

[Bug 12141] <video> Specifically state that all <track> options be exposed to the end user

From: <bugzilla@jessica.w3.org>
Date: Thu, 11 Aug 2011 23:53:26 +0000
To: public-html-a11y@w3.org
Message-Id: <E1Qrf42-0004N7-S3@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12141

--- Comment #17 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Thursday, 11 August 2011 23:53:28 GMT

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