Re: Change Proposal for Issue 194

>>> This is exactly the problem Sylvia refers to above. 
>> I don't think so.
> It actually was. :-) But I leave this discussion to Charles and John, who are much more knowledgeable about hiding content than I am.

<snip>

> > ... this distinction is 
> part of why I've occupied a controversialist position with respect to 
> references into @hidden. 
> > I do not believe it's good practice for publishers to hide transcript links.

Ben, like it or not, there are numerous ways to hide content from sighted users available to web authors today. Some are fairly good (but not perfect) in terms of usability for all users, and some are less so, and some are just plain stupid. It's not that hard to find examples in all 3 categories, and while you may feel that taking the stand "never hide things" is controversial (it isn't), it is neither practical, nor enforceable, and so it suffers a fatal flaw: not everyone agrees with you, and techniques (bad and less bad) exist today.

One of the goals here is to recognize all author perspectives, and one of the key aspects of this CP is that @transcript would present a "selection" switch in the chrome of the media player: likely a button or drop-down menu, but designers are free to experiment, and given how many scripted controls we're already seeing for native video, I expect that controls supporting transcript acquisition will surface very quickly with the introduction of @transcript. So now we will be able to "hide" the acquisition mechanism in plain site; it'll be in the controls (perhaps right beside the CC button).

Further, with this pattern if you wanted to show a text link on screen you could with a bit of scripting - it would be a progressive enhancement on the "native" behavior of being a 'button'. So here you get to have your Benjamin cake and eat it to - this is far simpler than going in the other direction.


>> <video src="whatever"><a href="whatever">Video</a></video> > 
>> <transcript src=""> does not.

So you are concerned with backward comparability? Would this calm your concerns?

     <transcript src="whatever" id="tr1"><a href="whatever">Transcript</a></transcript> 

...essentially a re-use of the <video> pattern: simple, obvious, easy to both author and explain - the link is the fallback when <transcript> isn't supported. The IDREF association still goes to the <transcript> container: in supporting browsers it then would load the transcript inside the container on the 'button' click. For non-supporting browsers, the <transcript> element degrades to a non-semantic <div>, and/but the button click moves focus to that 'div', and the next focus able item is the anchor link.

The one thing I think that will gain little support is the one which suggests that access to a transcript can ONLY be achieved by using <a href="">transcript</a>: d links failed a decade ago, when design esthetics still tolerated java applets and spinning mailboxes, and will surely meet equal resistance today. (Arguments that this is what we are getting today carry little water, as most videos DON'T have transcripts - perhaps because linking them via text links is ugly...)

JF

Received on Thursday, 24 May 2012 04:23:06 UTC