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

On Tue, May 29, 2012 at 8:01 PM, Janina Sajka <janina@rednote.net> wrote:
> The Task Force Media Subteam has concluded work on a change proposal for
> Issue-194: Video Transcript:
>
> http://www.w3.org/html/wg/wiki/ISSUE-194/TranscriptElement
>
> On 31 May next the HTML-A11Y Task Force teleconference meeting will
> consider consensus support of this Issue-194 Change Proposal
>
> As usual, if there is objection in the Task Force to such a consensus
> position, please respond by replying to this message no later than close
> of business, Boston Time, on Thursday 31 May.

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.

+ 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 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?

<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>

and

<video transcript="t1 t2" src=video.mp4></video>
<transcript>
  <a href="transcript.html">Transcript - English</a>
</transcript>
<transcript id=t2>
  <a href="transkript.rtf" hreflang=de>Transcript - German</a>
</transcript>

+ 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 …

"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.

"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?

"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.

"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.

"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.

"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>.

"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.

"Automated rendering of interactive transcripts from a TextTrack file
is not possible with such a solution"

A :transcript CSS pseudo-element would enable this.

"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". 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.

"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?

"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.

"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?

--
Benjamin Hawkes-Lewis

Received on Tuesday, 29 May 2012 22:14:44 UTC