Re: 48-Hour Consensus Call: Issue-194 Change Proposal

Hi Ben,

Many things to address, so I want to do this early. Shouldn't stop
anyone else to provide feedback, too.


On Wed, May 30, 2012 at 8:13 AM, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com> wrote:
>
> I have some objections to the CP in its current form.
>
> + Objection 1
>
> The CP is missing critical edit instructions, such as proposed
> verbiage for what a transcript element "represents" or what it means
> if a @transcript attribute points to an idref that isn't a
> <transcript> element, perhaps amongst other idrefs that are! Please
> make it clear what text needs to be added to the spec.

I can provide explicit edit instructions, but I know that Ian prefers
to write those himself to keep with the style. I know there is another
round of discussions at the HTML WG to come before we get there
anyway.

As for the problem of @transcript pointing to non-transcript
elements... that is a very good point. I think the suggestion from
Mozilla to use an attribute that is more like @mediagroup makes a lot
of sense. Maybe it would be better to associate a <transcript> element
with a media controller if they are associated and introduce the
concept of a slaved transcript element. This would work particularly
well with an interactive transcript. For non-interactive transcripts
we have not timeline to slave towards, so that could be a bit weird.


> + Objection 2
>
> I don't understand the point of mentioning @aria-label in "Satisfying
> [UC1] linked transcripts". Seems redundant with good link text and
> there's seemingly no new requirements for authors or user agents here,
> so it's confusing to mention it.

The main use case for @aria-label is to provide text to render in the
menu that browsers will want to render on top of the video to link to
a transcript.
You could regard it as redundant and just use the link text for UC1,
but then it won't work for the other use cases.

Likely @aria-label is not the best choice of attribute name for this
use, since it also has an existing different use. Maybe we should
replace that with @label (just like on the <track> element)?


> The CP proposes very complicated
> markup for the task of linking to transcripts in multiple languages in
> "Satisfying [UC2] on-page transcripts":
>
> <video transcript="t1 t2" src=video.mp4></video>
> <transcript id=t1 lang=en aria-label="English transcript">
>  <a href="transcript.html">Transcript for the video</a>
> </transcript>
> <transcript id=t2 lang=de aria-label="German transcript">
>  <a href="transkript.rtf">Transkript fuer das Video</a>
> </transcript>
>
> Why not just let UAs make use of the @lang and @hreflang attributes
> and generate appropriate UI text?

We don't do automated text creation for the caption track menu either
- we have @label on the <track> element for this. The use of
@aria-label follows this pattern.

As for keeping separate transcripts in their own transcript element:
the use case for this is to allow their identification as separate
entries in the video player menu. If we mash all of the links together
under one <transcript> element and mix it with text and headers etc,
then it's pretty difficult for the browser to identify them as
separate transcripts. They need to be individually identified through
a @transcript IDREF to get a separate menu entry.


> <video transcript="t1 t2" src=video.mp4></video>
> <transcript>
>  <a href="transcript.html">Transcript</a>
> </transcript>
> <transcript id=t2 lang=de>
>  <a href="transkript.rtf">Transkript</a>
> </transcript>

(I assume you're missing id=t1 on the first <transcript> element?)

Also, the text can likely be created from the <a> elements in this
case, but not in the other use cases.

Finally: what is written on the page may be more verbose than what you
want to put into a menu item, e.g.

<video transcript="t1 t2" src=video.mp4></video>
<h3>Transcripts</h3>
<ul>
<li><transcript id=t1 label="Transcript - English">
     <a href="transcript.html">Full-text English transcript</a>
     <input type="button" value="Download Now"/>
    </transcript>
</li>
<li><transcript id=t2 lang=de label="Transcript - German">
     <a href="transkript.rtf">Volltext deutsches Transkript</a>
     <input type="button" value="Herunterladen"/>
    </transcript>
</li>
</ul>


> + Objection 3
>
> The reasons given in "Advantages in comparison to a plain IDREFs
> @transcript attribute only" are often dubious. To address them point
> by point …

Yeah, that section may need a clean-up - I just threw together what
came to mind without having fully thought it through. That's why
having this discussion is good.


> "There is no explicit semantic element that allows for the
> identification of transcripts - it all has to go through the
> video/audio element. Transcripts being semantically hidden and not
> explicitly called out on the page make them second-class citizens on
> the Web. This is particularly problematic for Use Case 4 where there
> is no media element on the page, but possibly a download link close or
> even part of the transcript element."
>
> The civil rights rhetoric being co-opted here is empty. Are <sentence>
> and <argument> second-class citizens on the web because they don't
> have an element? What's more semantic about an element than an
> attribute anyway? Cite some plausible impacts on end-users of not
> identifying standalone transcripts. As far as I can tell, for such an
> element to be really useful you'd need to be able to reliably
> associate some media somewhere with the transcript, and the CP doesn't
> provide one.

I don't understand - we introduced <article> and <footer> claiming
these arguments. Why are they not acceptable for <transcript> ?

The indirection problem is definitely a problem - whenever you want to
identify transcripts on a page, you have to find the video or audio
elements first and then link through to the other elements on the page
that are referenced. That makes transcripts second-class.
(It's not a civil rights argument - it's a technical argument.)

If you forget to put the IDREF or the id on the elements on either end
(as you did in the example above), you have no way of recovering. With
a <transcript> element, you can at least identify intent. It's more
robust.


> "A <transcript> element can receive an aria landmark so you can jump
> directly to them with AT - this is not possible for the indirect
> identification of transcripts through a video/audio element and
> impossible without a media element."
>
> Why can't the targets of @transcript can be exposed to navigation just the same?

You'd have to introduce a new @role value and mark up the elements
that are supposed to be transcripts with @role="transcript". That's a
patch for the situation where we don't have a semantic element in
HTML. Why not solve the problem properly?


> "There is a multitude of markup possibilities (IDREF to anchor, div,
> iframe, p, textarea, article, footer etc elements) but not a uniform
> solution. This is particularly problematic when providing default
> styling both by the browser and by the Web app developer. It is also
> much harder to find when manually editing or when scripting."
>
> @transcript could be a uniform solution in this respect if we
> introduced a CSS :transcript pseudo-element comparable to :target.

So, above you've suggested to patch WAI ARIA roles, and now you're
suggesting to patch CSS as well? Why should we have to make changes to
all other specs, when a simple addition to the HTML spec would solve
all of the issues?


> "A <transcript> element would be "sectioning content" and thus define
> the scope of headers, see
> http://www.w3.org/TR/html5/content-models.html#sectioning-content ."
>
> This is true.

OK.


> "Marking <a>, <div>, <p>, &;lt;iframe>, or any other element as a
> transcript-containing element is unclean and ugly - a <transcript>
> element is elegant and extensible for further new transcript-related
> features."
>
> Having to use an attribute plus an element of the same name doesn't
> seem obviously less ugly than using just an attribute. It's also not
> clear that the element supports new features whereas the attribute
> does not, at least, not any that couldn't be supported by adding an
> element later.

The required introduction of a new @role value and of a new CSS
pseudo-selector, and the lack of ability to provide a specific label
for a menu on the video seem to me enough ugliness.

The most outstanding new feature is the interactive transcript
rendering from <track> elements. How would you do that with just an
@transcript attribute?

Finally, why add an element later and thus introduce different
solutions for transcripts, when one element now would cover them all
and be extensible?


> "There is no obvious means to provide a label for the
> transcript/transcript link that could be provided in a menu in the
> video element. For a <transcript> element we can use @aria-label (or
> something else more adequate)."
>
> This doesn't make sense. @aria-label designates the accessible name
> for a container, it doesn't matter whether the container is a
> <transcript> or a <div>.

Yeah, @aria-label is not a good choice. Let's use @label instead.


> "A @transcript pointing to a div or p element is essentially the same
> as pointing @aria-describedby at a div or p - these uses may become
> confused if transcripts are not more explicitly dealt with."
>
> This seems implausible. More likely users will incorrectly imagine
> that @transcript will work the same way as @aria-describedby and not
> require a seemingly redundant element too.

We could argue about developer expectations forever. ;-)
Should probably remove this argument.


> "Automated rendering of interactive transcripts from a TextTrack file
> is not possible with such a solution"
>
> A :transcript CSS pseudo-element would enable this.

How would that work?

Would you have a <track> element inside the <video> element that
references the transcript vtt file, then a div that is linked through
@transcript from the video element into which the browser is expected
to render the vtt file? Then video :transcript would allow you to
style the div's content?
This is the first time that we'd have a div element's content in HTML
being rendered by the browser - would it be in the shadow DOM? What do
you do when the linked element is not a div element?

I am indeed waiting for a counter-CP that explains how to do all of
these things with just IDREFs - I've failed to make it work, which is
why I ended up with a <transcript> element.


> "Even if the user forgets to mark up the video with an @transcript
> attribute, a <transcript> element will still be announced as
> transcript content to AT, thus being more robust."
>
> I think this should say "might be announced" not "will".

OK.

> Redundancy
> provides more opportunities for people to get things wrong as well as
> right. For example, authors might not realize they need to markup the
> transcript with an element as well as pointing to it with an
> attribute.

That's a problem with a @transcript attribute alone, too: people may
continue to do what they do today without providing the linkage.

It's much easier to advertise and learn the availability of an
explicit <transcript> element: I simply remember that whenever I want
to publish a transcript, I put it in a transcript element. If I want
to link it to a video element, I add the @transcript attribute on the
video. This works if my video is published in an <embed>, in an <a> or
in any other form.

In comparison: If I want to publish a transcript, I put @transcript
attribute on a video element. Hmm, but I don't have a <video>
element... what now?

This is particularly a problem if I am authoring the transcript code
on the page, but have nothing to do with the video publishing. What if
the video comes from a different Website and I can't even provide the
linkage? At least in this way I can mark up my transcript area as
such. Search engines will be clever enough to find a <transcript>
element, see a video on the page and provide that linking through
heuristics.


> "Transcript-specific features can be introduced more easily with an
> explicit <transcript> element, e.g. automatically download with the
> video page for offline viewing."
>
> Why should that be easier?

Same kind of heuristics apply as for search engines where the
@transcript has been forgotten on the video element, or the video is
provided through a different means (e.g. <embed>, <a>).


> "Using an explicit <transcript> element actually encourages publishers
> to keep their transcripts visible on page and include them in their
> published content to the advantage of all users."
>
> I don't see how it does anything of the sort.

OK, not worth arguing about intent.


> "It makes it a first class feature."
>
> There's nothing first-class about elements and second-class about
> attributes. Are <abbr> and <address> and <ins> somehow more
> first-class than @class and @lang and @onclick?

It's the indirection that makes it second-class. @transcript does not
contain the transcript itself (which would be "first-class"), but
links to another element that has the transcript.

Thanks for the great feedback!

Cheers,
Silvia.

Received on Wednesday, 30 May 2012 01:52:12 UTC