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

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.

Regards,
Silvia.

Received on Thursday, 22 March 2012 21:32:26 UTC