W3C home > Mailing lists > Public > public-html@w3.org > March 2012

Re: CP, ISSUE-30: Link longdesc to role of img [Was: hypothetical question on longdesc]

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
Message-ID: <20120322224414.GA5655@sonata.rednote.net>
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:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:47 GMT