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

Re: discussion of video transcript - issue 194

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 15 May 2012 03:39:35 -0700
Cc: John Foliot <john@foliot.ca>, HTML Accessibility Task Force <public-html-a11y@w3.org>, Judy Brewer <jbrewer@w3.org>
Message-id: <608C36ED-E4AF-449D-B20E-09201A1581AA@apple.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>

On May 10, 2012, at 12:58 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:

> Here is the first draft of a proposal that we've recently started
> discussing at Google:
> http://www.w3.org/html/wg/wiki/ChangeProposal/Issue194_SP
> Please read with an open mind and feel free to make suggestions for improvement.

Implementor feedback and with chair hat off:

It is much more efficient, implementation-wise, for the video to link to the transcripts, than for the transcripts to link to the video. Often, the engine will want to perform an operation where it has the video element as a starting point, and it wants to find all associated transcripts. For instance, it may wish to find all tanscripts to build a menu. Or it may be running with an assistive technology enabled which gives the user the ability to go straight to the transcript when the acessibility point of regard (e.g. the VoiceOver cursor in VoiceOver) is at the video.

If the video links to transcripts by id, then this is straightforward. The engine simply does a getElementById() for each associated transcript ID, an operation which is already optimized to return in average-case amortized constant time in browser engines.

However, the other way around is much more expensive. If you are at a video and need to find all transcripts linking to it with @for, you have the choice of one of:

1) Walk the whole document to find all <transcript> elements, and collect ones with the right @for association. This can be slow for a large document, enough to be unacceptable for interactive response to a user operation.

2) Maintain an extra data structure on the side which knows about all <transcript> elements and all media elements currently in the document, and maps the forward association; this would cost extra memory, and would require a lot of care to handle dynamic updates properly (when elements get added/removed, when ids change, when for attributes change, etc).

It is not clear to me what advantage there is to <transcripts> linking back to the <video> or <audio>, instead of forward linking from the media element to associated transcripts. Unless there is a compelling advantage, I would suggest switching to forward linking.


P.S. In this regard I believe the design of the <label> element and its @for attribute is poor, and the design of aria-labeledby is superior.
Received on Tuesday, 15 May 2012 10:40:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:28 UTC