Re: discussion of video transcript - issue 194

On Fri, May 11, 2012 at 3:46 AM, John Foliot <john@foliot.ca> wrote:
> 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>

BTW: They are not 3 different proposals. They are three use cases that
I showed how to satisfy with the same proposal. Just in case that
wasn't clear.

Cheers,
Silvia.

Received on Friday, 11 May 2012 13:03:51 UTC