RE: [media] Moving towards a consensus for video transcripts

Silvia Pfeiffer wrote:
> 
> In summary: we've made huge progress and are moving towards a
> consensus CP. 

+1


> We haven't exactly addressed all the details and some
> objections still exist, but we believe that within a week and with the
> next media a11y TF phone conference we can actually come up with a
> consensus CP.
> 
> Here are some more details:
> * we believe that it is preferable to have a unified solution for the
> different use cases for transcripts
> * we believe that there should be default rendering of transcripts and
> off-page transcript links by the browser
> * we prefer not to introduce an explosion of buttons on the page to
> select between different text alternatives for media

Points 2 and 3 seem to be in conflict with each other, and in many ways they
are, but there is a strong feeling that an on-page text only link is, while
certainly one option, also somewhat archaic and will be avoided as often as
used because of design considerations. Having a mechanism that indicates the
presence of a transcript rendered somehow by the browser (browser chrome,
player chrome, button, something...) is an important, but tricky balance to
meet. There has been some useful discussion on this point, but more input
would be welcome.


> * we prefer re-using the <track> element for 'interactive transcripts'
> (as defined by wikipedia [3])
> 
> After analysing the different options listed in the transcript
> research page [4] and the latest proposal [5], we generally agreed
> that introduction of a landmark element called <transcript> seems to
> be a good idea. It is particularly advantageous to enable browser
> rendering of interactive transcripts in this way. The details of how
> <transcript> would work with non-interactive transcripts are, however,
> not agreed yet.
> 
> It is those details that we will be working through in the next media
> a11y TF meeting.
> 
> Some of the issues that need to be discussed are:
> 
> * would a @transcript attribute on the video element be better than a
> @for attribute on the transcript element?
>   + it would encourage introduction of a transcript menu in the video
controls
>   + it could be a list of IDREFs and thus allow linking to different
> transcripts in different areas on the page
> 
> * one problem is that <a> elements inside a <transcript> (e.g. to link
> to doc or pdf transcripts) would be focusable even when hidden from
> sight
>   -> maybe we can avoid using <a> elements, but how?

This is a significant potential problem. A list of links placed in a div
off-screen will still take tab focus, but will not actually show where that
focus is for sighted, keyboard only users. While we have this problem today
(the notorious skip-nav links) moving forward a design that does not
encourage this kind of poor user-experience is a key goal.


> 
> * how can we support downloading of transcripts so they can be read,
> e.g. on the plane?
>   -> put a context menu link on <video>? on <transcript>? on both?
> 
> We would like to encourage in particular browser vendor comment on
> proposal [5] and the issues above, and would like to invite them to
> participate in next week's media accessibility TF meeting, which
> should be announced shortly.

The official meeting time will be announced soon. However, unofficially it
is scheduled for Thursday May 17th at 5:30 PM Boston (21:30:00 UTC). Your
participation is welcomed.

> 
> I'd also particularly like to ask for Ian's comments/suggestions given
> his extensive design experience as the HTML spec editor.
> 
> Best Regards,
> Silvia.

Cheers!

JF

Received on Saturday, 12 May 2012 01:55:05 UTC