Re: [media] progress on video transcript discussion

I've been tied up with WebKit/Chrome coding, but am slowly making
progress on the next proposal. It's been emailed and discussed, but
not properly written up.

When Apple is back from WWDC next week and I've done my new CP, I'm
expecting to get that consensus worked out.

Cheers,
Silvia.

On Thu, Jun 14, 2012 at 7:52 AM, Janina Sajka <janina@rednote.net>
(janina@rednote.net) <janina@rednote.net> wrote:
> Paul:
>
> Any reason we can't do this on the TF and WG calls tomorrow?
>
> The fundamental answer is: "Yes, we have progress." But, Apple's been
> tied up in their WWDC this week. This is blocking us on this issue and a
> few others.
>
> Janina
>
> Paul Cotton writes:
>> > OK, let's see if we can get consensus. :-)
>>
>> Where do we stand on a consensus proposal for ISSUE-194: full-transcript?
>> http://dev.w3.org/html5/status/issue-status.html#ISSUE-194
>>
>> /paulc
>>
>> Paul Cotton, Microsoft Canada
>> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3
>> Tel: (425) 705-9596 Fax: (425) 936-7329
>>
>>
>> -----Original Message-----
>> From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]
>> Sent: Friday, June 08, 2012 6:47 PM
>> To: John Foliot
>> Cc: David MacDonald; HTML Accessibility Task Force; Edward O'Connor; chaals@opera.com; Eric Carlson
>> Subject: Re: [media] progress on video transcript discussion
>>
>> On Sat, Jun 9, 2012 at 1:54 AM, John Foliot <john@foliot.ca> wrote:
>> > Silvia Pfeiffer wrote:
>> >>
>> >> OK, sorry, I mis-wrote. I am using ARIA only where blind and
>> >> vision-impaired users need it. For all other needs I have proposed a
>> >> generic solution.
>> >>
>> >> When the transcript is not visible, there is a link.
>> >> When the transcript is visible, they can see it and don't need any
>> >> more notice.
>> >> So, there is no problem.
>> >
>> >
>> > Here is a use-case where this is a problem:
>> >
>> > <div>
>> > <video src="video.mpg" aria-label="video with transcript below"
>> > transcript="@this_page#transcript"></video>
>> >
>> > <a href="transcript.html" hidden>Transcript</a>
>> >
>> > *or*
>> >
>> > <a href="transcript.html" style="margin-left:-999px; position:
>> > absolute;">Transcript</a>
>> >
>> > *or*
>> >
>> > <a href="transcript.html" style="display:none;">Transcript</a>
>> >
>> > *or {shudder}*
>> >
>> > <a href="transcript.html" aria-hidden="true">Transcript</a>
>>
>>
>> In all these use cases, the sighted user sees no transcript either, so the best thing to do here is to discourage this usage completely since it is not good for ANY user.
>>
>> If it happens, however, then the aria-label attribute needs to say aria-label="transcript available" and the @transcript=URL will point to it, exposed in the context menu, button on the player of whichever suits the video player best.
>>
>> It is therefore a use case that is covered with my suggestion.
>>
>>
>> > Here is another troubling use-case:
>> >
>> > <video src="video.mpg" transcript="@this_page#transcript"></video>
>> >
>> > <p>Lorem ipsum dolor sit amet...</p>
>> > <p>Lorem ipsum dolor sit amet...</p>
>> > <p>Lorem ipsum dolor sit amet...</p>
>> > <p>Lorem ipsum dolor sit amet...</p>
>> > <p>Lorem ipsum dolor sit amet...</p>
>> > <p>Lorem ipsum dolor sit amet...</p>
>> >
>> > <footer style="font-size: 8px;">Download the <a
>> > href="transcript.html">transcript</a> here | <a
>> > href="privacy.html">Privacy Policy</a> | {etc.}</footer>
>> >
>> > Problems:
>> > 1) the cut and paste concern we continue to have
>>
>>
>> There is a @transcript=URL attribute in the video, which will be cut and pasted as well. Thus my suggestion to encourage authors to only use absolute URLs in this attribute. Then we avoid this problem.
>>
>>
>> > 2) users with low vision who are using a screen magnifier that does
>> > not render the entire screen in view, but rather a portion of that
>> > screen. The distance between the video element and the link to the
>> > transcript makes discovery problematic (compounded by the fact that in
>> > this scenario, the link has been 'dumped' into the footer along with
>> > all the other pesky stuff like copyright notice and privacy statement;
>> > is rendered as smaller text; and generally treated as a necessary
>> > evil)
>> >
>> > Even in this use-case, if we applied an aria linkage for blind users,
>> > it would not solve the problem for the low-vision user who is using a
>> > screen magnifier and not a screen reader.
>>
>> Indeed - the aria attributes don't help, but the @transcript=URL attribute solves this use case, too.
>>
>>
>>
>> >> >> Since it is now very clearly a
>> >> >> link, it is indeed possible for developers to experiment with
>> >> buttons
>> >> >> or other interaction mechanisms on the video player if they want to.
>> >> >> So, I think it meets the requirement that you're posing.
>> >> >
>> >> > Yes, it does indeed.
>> >>
>> >> Well, this is what I care about. :-)
>> >
>> > And this is indeed the most important common-ground we share, so do
>> > not become frustrated by my responses.
>>
>> OK, let's see if we can get consensus. :-)
>>
>> Cheers,
>> Silvia.
>>
>>
>
> --
>
> Janina Sajka,   Phone:  +1.443.300.2200
>                        sip:janina@asterisk.rednote.net
>                Email:  janina@rednote.net
>
> The Linux Foundation
> Chair, Open Accessibility:      http://a11y.org
>
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair,  Protocols & Formats     http://www.w3.org/wai/pf
>        Indie UI                        http://www.w3.org/WAI/IndieUI/
>

Received on Wednesday, 13 June 2012 23:06:14 UTC