RE: discussion of video transcript - issue 194

Silvia Pfeiffer 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.

Open-minded response:

For the most part, I like some of what you are proposing. I have heard
previously that 'overloading' the video element with yet another new child
element was computationally heavy (this comment came from Frank Olivier in
the context of my proposed <firstframe> / <poster> child element.)

That said, if we can get some buy-in from browser vendors to support a new
<transcript> child element, I believe it meets the key requirements that
have been identified, especially the ones you noted as:

  (10) transcripts may be exposed in video controls, because when media
elements are taken fullscreen, the transcript link still needs to be visible

  (13) transcript link duplication should be avoided

And I would add a number 17 and 18 to your list:

  (17) it should be easy for authors who are already publishing content
(manually or with a WYSIWYG editor) to easily add transcripts

  (18) the programmatic linkage to a transcript should be easy to preserve
when authors cut-and-paste media content for re-use (i.e. keep the linkage
inside of <video></video>)


*******************

With regard to your observations:

1) "All three real-world use cases expose the transcript or transcript link
explicitly on the Web page. This makes sense, since transcripts are useful
to all users (as requirement 8 states), and need to be exposed to all users
(req 9)."

	This is too simplistic a response. We have too many instances of
authors today seeking ways to "hide" links and other stuff "for blind users
[sic]", as recent blog posts[1] and even HTML WG Issues[2] will attest to. A
dogmatic instance that transcript links MUST ALWAYS be exposed as text links
on the page is a barrier to progress that needs to be recognized and
addressed. I also refer back to your own user-requirement #10 - when a video
is full-screen, an "on-page text link" is no longer present.

[1] 
http://www.marcozehe.de/2012/04/24/hiding-content-untangled-hiding-vs-moving
-out-of-the-visible-viewport/ (Marco Zehe - Apr. 24, 2012)
http://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-a
nd-aria-hidden/ (Steve Faulkner - May 1, 2012)

[2] 
HTML5 - Issue 204, ARIA-HIDDEN -
http://www.w3.org/html/wg/tracker/issues/204 

***

2) None of the real-world use cases expose a transcript link button in the
video player itself. There is a reason this is not done: once in the video
element - and in particular when full screen - everything that is clicked on
the video retains you in the video viewing experience - such a link
wouldn't.

	Today. 

	As previously noted, Jonas Sicking has stated "this is software, we
can do anything":
(http://lists.w3.org/Archives/Public/public-html/2011Mar/0627.html). You are
introducing complexity where none need exist. 

Silvia, we have already discussed the need and use-cases for rich
timed-text, including the ability to provide hyperlinks directly into that
timed-text.[3] How would the full-screen/touch-device scenario handle that
situation? Please be a bit more creative in your thinking here: as I always
tell my daughters, "don't say can't, say how?".

[3
http://www.w3.org/WAI/PF/media-accessibility-reqs/#enhanced-captions-subtitl
es - [ECC-2] Support hyperlinks and other activation mechanisms for
supplementary data for (sections of) caption text.]

***

3) None of the real-world use cases expose a transcript link in the context
menu either. Context menus don't easily translate to touch devices, so
advanced functionality is avoided in context menus.

	This is a device-dependant problem, and is the same problem users
will have for accessing closed captions, subtitles, chapter-cues, and any
and all of the other <track> @kind values - which currently today are all
accessed via the controls menu. This argument has very little weight in my
mind, as whatever device/platform-dependant solution emerges for accessing
closed captions can also apply to transcripts. There is no reason why not.

***

4) When video players provide a fullscreen experience of a transcript with
the video, it is an interactive transcript. Players that have a transcript
included (e.g. Drupal BuildAModule) are not just video players any more:
they have an extra area next to the video in which the transcript is
provided. The two sections go fullscreen together.

	This seems to answer one of your earlier concerns: "...once in the
video element - and in particular when full screen - everything that is
clicked on the video retains you in the video viewing experience..." In
these instances, the media controls are dealt with as part of that larger
full-screen experience - they "go together" in your words, and access to the
interactive transcript remains available for all. I am failing to see a
problem here.

***************

I note with interest that you mentioned my friends Josh, CJ, Tole and the
rest of the 3PlayMedia gang in your Use Case section. You stated that their
interactive transcripts include time-stamping (and I was already aware of
that), which means that at least *their* transcripts could be good
candidates for <track kind="transcript"> because, well, the transcripts are
timed <grin>. I have included them on the CC list, as well as the
public-texttrack (community group) list, in case anyone there might have
some thoughts to offer here.

***************

Looking at the patterns you have brought forward:

Pattern 1:

<video id=v1 src=video.mp4></video>
<transcript for=v1 id=t1>
 <track src=transcript1.html srclang=en default>
 <track src=transcript2.html srclang=de>
</transcript>

I think that could work (how are users notified of the existence of the
transcript?), but why not also:

<video id=v1 src=video.mp4>
  <transcript for=v1 id=t1>
   <track src=transcript1.html srclang=en default>
   <track src=transcript2.html srclang=de>
  </transcript>
</video>

See my requirement #18. 

I also note that this is a re-use of @track (which I've proposed) albeit in
a slightly different manner. Finally, as previously stated I think that the
INSISTANCE of "on screen text" is overly prescriptive and does not match
what real-world devs want to do today. Please do not take this down the
@longdesc sinkhole debate track, as it will shut down any further discussion
at this end (at least).

***

Pattern 2:

<video id=v1 src=video.mp4></video>
<transcript for=v1 id=t1>
 <a href=transcript.html>Transcript for the video</a>
</transcript>

I find this somewhat clunky from an authoring perspective; <transcript>
could take the href attribute directly for a cleaner and clearer authoring
pattern.  I also again reject any instance of REQUIRED "on-screen text".

***

Pattern 3:

<video id=v1 src=video.mp4></video>
<transcript for=v1 id=t1>
 <p>This is an on-page transcript.</p>
</transcript>

Outside of the probability that most transcripts will be too large/long to
be directly included on the same page as the media asset, this pattern again
suffers from the over-arching issue with the on-screen text link
requirement.

That said, if there was a proposal that merged the ideas of Patterns 2 and 3
together, with some modification, I think that this could work as well:

<video id=v1 src=video.mp4>
  <transcript for=v1>
     <a href=transcript.html>Transcript for the video</a> 
** OR **
     <p>This is an on-page transcript.</p> 
  </transcript>
</video>


***************

JF

Received on Thursday, 10 May 2012 17:47:39 UTC