RE: [media] progress on video transcript discussion

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>

(more likely done like this: <a href="transcript.html" hidden
aria-hidden="true">Transcript</a> - where the developer has read somewhere
that they should double up on both the html5 attribute and the aria
attribute to make it work for all users - and do not put this past some
developers!)

</div>

As Chaals and I have repeatedly stated, there are numerous ways that authors
will hide content from sighted users but try to leave it there for
non-sighted users, as they believe they are doing the right thing given the
design constrictions they operate under. The problem is that most of these
techniques have weaknesses that fail some users as often as not. We have
more anecdotal evidence of this than I care to dredge up for this discussion
(but will if pressed - please trust me here).  I will however offer as one
current example of the confusion and desire for this kind of behavior can be
found in the current Issue 204 discussions. Recent blog posts by Marco Zehe
(Mozilla)[1] and Steve Faulkner (TPG)[2] as well as conference presentations
by Victor Tsaran (Yahoo!)[3] all point to both the prevalence of this desire
and the problems associated to it.

1.
http://www.marcozehe.de/2012/04/24/hiding-content-untangled-hiding-vs-moving
-out-of-the-visible-viewport/ 
2.
http://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-a
nd-aria-hidden/ 
3. http://openwebcamp.org/events/53 


> 
> You still haven't read my full email and proposal. It makes me really
> sad when you ignore half of what I am saying and twist the first half
> without seeing the full picture.

Silvia, I *have* read your proposal, and have spent a significant amount of
time working with you and the rest of the active participants in this
thread/effort to get this right. I have been supportive of a number of
ideas, and have shown a fair bit of willingness to be flexible towards
finding a consensus position. My concern is that *MY* concerns are not being
heard.

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

> 
> My reasoning is much more sound now and it is a complete solution
> proposal. We have made huge progress since then. Sometimes one comes
> back to what was proposed earlier because one has excluded use cases
> that can now be satisfied differently. Seeing the complete picture is
> very important.

My bad for perhaps seeing the bigger picture from the on-set and not taking
the time to better articulate it.

I am somewhat troubled when you suggest that different use-cases can be
solved using different methods. While I am a huge proponent of giving
authors as many accessible choices as we can, I temper that by also seeking
a common solution for all use-cases whenever possible, and so a common
solution for all uses in this discussion is my preferred resolution.


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

JF

Received on Friday, 8 June 2012 15:55:32 UTC