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

RE: discussion of video transcript - issue 194

From: John Foliot <john@foliot.ca>
Date: Thu, 10 May 2012 09:23:39 -0700
To: "'Benjamin Hawkes-Lewis'" <bhawkeslewis@googlemail.com>, "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>
Cc: "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'Judy Brewer'" <jbrewer@w3.org>
Message-ID: <000801cd2ec9$44173c10$cc45b430$@ca>
Benjamin Hawkes-Lewis wrote:
> <transcript>
> <video id=v1 src=video.mp4></video>
> <p>This is a on-page transcript.</p>
> </transcript>

Yech. From an authoring perspective, that is a very ugly and confusing pattern to propose, even if it would technically be viable. It seems to suggest that the video is a child of the Transcript, which is both false and *really* confusing. I've re-authored your proposal to take advantage of indented nesting, which more clearly illustrates what I mean:


I might also note that most transcripts will not be "on-page" due to their size and volume of content. They will most likely be external documents in (hopefully) HTML, but also quite possibly PDF, Doc/Open Office, perhaps even Daisy - all viable and possible options today.

I am not a big fan of that at all.

> There might be rationale to make the following work as well:
> <video id=v1 src=video.mp4></video>
> <transcript>
> <p>This is a on-page transcript.</p>
> </transcript>

This seems to insist that the link to the transcript be an on-screen text link, which many of us feel is too simplistic a response.  If you want to take your analogy of <label> further, I ask you - how often do we currently see 
<label class="CSS_off_screen_because_onscreen_is_ugly">?

(I will suggest the answer is Very Often)

My concern is that using such a blunt work-around is hardly elegant, and once again might suffer from the orphaned link-to-transcript problem when authors cut and paste a <video> all the stuff </video> block - remembering that what *they* want is the video first.

My preference then would be that any solution discussed sees the vehicle for including the transcript be included inside the opening and closing <video> 'tags' (which @transcript, <track>, and apparently <transcript> would provide). 

>From the 'elegance' perspective, my preference would also be for something that could easily be incorporated into both the native as well as author-scripted controls that HTML5 offers. This would consistently follow a precedent already established by media players today, that expose a "CC" button inside of the controls bar whenever Closed Captions are available. While this would by no means restrict other presentation/delivery patterns, I would go so far as to suggest it might be recommended as the default way of doing so.


Received on Thursday, 10 May 2012 16:24:26 UTC

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