Re: Change Proposal for Issue 194

On Thu, May 24, 2012 at 7:10 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On May 23, 2012, at 2:46 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>
>>
>> When you have a video element on the page, yes. Note that I said "when
>> used without an actual <video> element".
>>
>> Here is an example where there is no video element on the page:
>>
>> <a href="video.avi">Download the video</a>
>> <transcript src="transcript.html">This is a video transcript</transcript>
>>
>> A search engine can discover this as a video transcript even without a
>> video element present on the page.
>
> Since the transcript is in no way associated with a specific video in this example, it's not clear why it is helpful to use a <transcript> element rather than an <a> element.

In this case there are indeed some heuristics necessary - proximity to
the <a> element, the use of the word "video" and the file resource's
mime type will identify the video. Almost always when video is
published with a transcript you will find that there is only one video
being described on that Web page, because otherwise it would be
information overload. The before mentioned heuristics will typically
work in either case. If that is not sufficient, it would also be
possible to recommend using a @aria-describedBy attribute on the <a>
element to point to the transcript element.


> It seems like the main effect is to prevent users from clicking on the transcript link.

I don't understand that conclusion. Can you elaborate?


On a side note: I would much prefer having an <a> element with the
link inside the <transcript> (see my original CP
http://www.w3.org/html/wg/wiki/ChangeProposal/Issue194_SP). Like this:

<video transcript="t1" src="video.webm></video>
<transcript id="t1" title="English video transcript" lang="en"><a
href="transcript.html">Here is the video transcript</a></transcript>

rather than

<video transcript="t1" src="video.webm></video>
<transcript id="t1" src="transcript.html" title="English video
transcript" srclang="en"></transcript>

It is easier to mark up. It is also easier to adapt currently
published transcript links to this spec.

However, I was told that if such a transcript element was hidden, the
<a> element would still have tab focus and thus create an  a11y
problem. I've actually tested this just today and I don't seem to be
able to tab to <a> elements in Safari, Firefox or Opera - only Chrome
still does this. Is this something that was changed in HTML5?

Anyway, I would prefer if we found a different solution to the problem
of focusable elements inside hidden content. I was thinking that we
could remove the DOM subtree of an invisible <transcript> element,
which then makes the problem go away. Or have a solution that makes
all focusable elements inside <transcript> take on @tabindex=-1 if
that was possible. Ideas welcome!


> And since the transcript is not associated with the vide content, browsers have no way to offer a better UI.

The better UI that I am referring to is not on the video element, but
on the transcript element. It doesn't need to be associated with a
video to provide that.

If you are concerned about a better UI on the video, there is no
difference between what Ted is suggesting (with IDREFs to any HTML
element) in comparison to my suggestion (with IDREFs to transcript
elements that then contain these other elements). The video's UI can
be improved for both of these proposals in exactly the same manner.

However, having an explicit <transcript> element allows us all kinds
of transcript-related UI improvements. This starts with having
identical preset CSS rules for all transcript elements and their child
elements. We can include certain keyboard shortcuts with the
<transcript> element in the browser, e.g. to take it fullscreen
(similar to how we can make video elements go fullscreen), and to use
arrow keys  or tab keys when focused on the <transcript> to navigate
within it. It certainly needs to allow for scrollbars if the text is
too long.

I am just brainstorming here - I think there are many details that
need to be worked out and I would love to have this discussion in the
larger WG (in particular with Ian) to make sure we come up with the
best possible solution on the details of a <transcript> element. All I
can say is that it is a semantically rich construct and thus needs
being dealt with as its own concept and not just as the crooked little
dependent of a media element.


> And the search engine has no way to know what video this transcript is a transcript for, so it's not clear how it benefits from knowing it is a transcript. Thus, I don't see how your example shows the benefits of a <transcript> element. Can you clarify please? What specifically would work better with this markup example than with <a>?

Styling. Event attachment. It would be "sectioning content" and thus
define the scope of headers, see
http://www.w3.org/TR/html5/content-models.html#sectioning-content .
For example in the first as well as the second case:

<transcript>
<h4>This is the transcript for xxx></h4>
<a href="transcript.html">View the transcript</a>
</transcript>

<transcript>
<h4>This is the transcript for xxx></h4>
<iframe src="transcript.html></iframe>
<a href="?download">Download the transcript</a>
<p> &copy; 2012 John Doe </p>
</transcript>

If we don't define what a transcript is and how to use it, and just
leave it as a IDREF to any other potential element on the Web page, we
can end up linking to another <video> element as a transcript, or a
<canvas>.

Also note that without a specific element, there is no defined way of
telling the <video> element (or any other rendered list) what label to
put into a menu of video transcripts. Right now, we haven't agreed on
how to specify it for the <transcript> element, but at least it is
obvious how to solve it, namely through an attribute on <transcript>
(we seem to suggest @aria-label or @title, but could be just @label).
This problem cannot be solved if we only introduce a @transcript
attribute with IDREFs.

Regards,
Silvia.

Received on Friday, 25 May 2012 05:12:19 UTC