- From: Janina Sajka <janina@rednote.net>
- Date: Thu, 22 Mar 2012 18:44:14 -0400
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: John Foliot <john@foliot.ca>, David Singer <singer@apple.com>, Sean Hayes <Sean.Hayes@microsoft.com>, ""'"'xn--mlform-iua@målform.no'" <xn--mlform-iua@xn--mlform-iua.no>, rubys@intertwingly.net, laura.lee.carlson@gmail.com, mjs@apple.com, Paul Cotton <Paul.Cotton@microsoft.com>, public-html-a11y@w3.org, public-html@w3.org
Silvia Pfeiffer writes: > On Fri, Mar 23, 2012 at 1:07 AM, Janina Sajka <janina@rednote.net> wrote: > > Silvia Pfeiffer writes: > >> On Thu, Mar 22, 2012 at 6:05 PM, John Foliot <john@foliot.ca> wrote: > >> > Silvia Pfeiffer wrote: > >> >> > >> >> <track> is a timed resource. Neither transcript, nor description, nor > >> >> posterdescription are timed - they cannot be parsed into cues and > >> >> displayed time-synchronously over the video. You cannot misuse the > >> >> track element in this way. > >> > > >> > Hmmm... I don’t recall seeing anywhere where it states that @kind="metadata" > >> > was required to be a timed resource - is that specifically stated somewhere? > >> > >> It's kinda hard to find, but it's there. > >> > >> For example, the definition of what a text track is in > >> http://www.w3.org/TR/html5/the-iframe-element.html#text-track-model > >> lists what a track consists of. > >> > >> One part of that is a list of cues: > >> http://www.w3.org/TR/html5/the-iframe-element.html#text-track-list-of-cues > >> i.e. each track consist of a list of cues. This is independent of what > >> kind of text track we're dealing with. > >> > >> And a little further on the actual definition of a text track through its cues: > >> "A text track cue is the unit of time-sensitive data in a text track, > >> corresponding for instance for subtitles and captions to the text that > >> appears at a particular time and disappears at another time." > >> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#text-track-list-of-cues > >> > >> The whole concept of text tracks is built around timed cues. > >> > > In retrospect perhaps calling them "text" tracks is an unfortunate > > misnomer. "Timed" tracks might have been better, less readily > > misunderstood. > > It's really short of "Timed Text Tracks". > > > > I suppose the term "text" tracks is a holdover from the early days when > > some of the HTML 5 people hadn't yet grocked the extensive range of > > alternative media required to support accessibility, i.e. a "sign > > language translation" is not a "text" track, though a caption certainly > > is. > > Well, the idea is to have a text alternative that AT can deal with. So > there is some merit to restricting it to "text". Naturally - since > we're on the Web - marked-up text is also regarded as text, so other > content could seep in, too. > > Also, there is a misunderstanding: Sign language video is not provided > through a <track> element. It is provided through a <video> element > that is synchronized to the video through a controller. We have more > than just text tracks as a solution to video accessibility needs. > > > > I recall our meeting at Stanford some years hence. Those of us from > > accessibility who were just joining the HTML 5 work effort found > > ourselves rather concerned at how disability support was being called > > "captioning," causing us to start insisting on a requirements gathering > > phase. > > > > Would future authoring be assisted by changing this to "timed" tracks > > now? Some pain, of course, but future gain? > > It might help to add a sentence explicitly explaining what text tracks > are. Maybe something like: they provide synchronized text-based cues > for the media element, traditionally called "timed text tracks". > > > > I don't see this as important as other discussions recently in this > > thread, but it did seem worth noting. > > Indeed, just a nit that we have to keep in mind. > What about annotating the Requirements document we prepared with pointers to the technology that implements them? Would that be a useful way for people to understand what aspects of HTML 5 media provide support for which specific alternative media renderings? Is this a useful way to extend the value of that document? You'll recall PF has put the Requirements doc on a W3C Note track. Would this kind of annotation help? Or just confuse? Janina > Regards, > Silvia. -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Chair, Open Accessibility janina@a11y.org Linux Foundation http://a11y.org Chair, Protocols & Formats Web Accessibility Initiative http://www.w3.org/wai/pf World Wide Web Consortium (W3C)
Received on Thursday, 22 March 2012 22:44:51 UTC