W3C home > Mailing lists > Public > public-html-a11y@w3.org > May 2012

Re: Change Proposal for Issue 194

From: Charles McCathieNevile <chaals@opera.com>
Date: Wed, 23 May 2012 22:31:03 +0200
Cc: "HTML Accessibility Task Force" <public-html-a11y@w3.org>
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>, "Benjamin Hawkes-Lewis" <bhawkeslewis@googlemail.com>
Message-ID: <op.wer291yxwxe0ny@widsith-3.local>
On Wed, 23 May 2012 10:11:40 +0200, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com> wrote:

> On Wed, May 23, 2012 at 7:53 AM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>>> It is unnecessary to mint a new element to satisfy UC1 (transcript as
>>> linked resource); it would be simpler for the IDREFs in transcript=""  
>>> to directly point at the <a> that links to the transcript.
>> I was told that hidden <a> elements are a real problem, since they
>> gain keyboard focus. Putting the link into a <div>-like element avoids
>> this.

[taken from further down...]
> So I don't understand the problems with:
>   <transcript><a href="url">Transcript</a></transcript>
[return to normal flow]

> Today, a simple link to a transcript is one of the two common ways of
> surfacing a transcript.
> Authors who want to hide the link can use CSS "display: none;"

This is exactly the problem Sylvia refers to above. This advice is all
over the web, and it leads to the content not being available. You've
effectively deleted it - and this is also used by many people who naively
find it somewhere and copy it. (I've attached a pretty dumb test case to
illustrate what happens - and it happens in a lot of places).

There are various other "solutions" to this problem, most of which  
introduce new problems. 15 years of trying to get it right suggests that  
putting things in then hiding them because they are only for screen  
readers is just an anti-pattern.

> in all
> browsers applying their CSS or HTML @tabindex="-1" to remove the link
> from the tab order in all browsers. If we continue to allow references
> into @hidden content, they could also use @hidden to hide the link.
> Alternatively, authors can leave the link in the tab order and use CSS
> or JS to ensure the link is visible on focus.
> Using a normal a@href has a better backwards compatibility story than
> adding an attribute to transcript.

Yes, and it is possible to do that still. Likewise, using a link to a  
video has a better backwards-compatibility story than the video element. I  
don't think the comparison is too far-fetched. If browsers do nothing, the  
transcripts will disappear. On the other hand there are strong regulatory  
pressures, and some large content producers who come from TV and are  
well-accustomed to transcripts of various kinds already. I think this is a  
reasonable case to look for implementation in the HTML5 time-scale and  
make the web work better, rather than trying to hold everyone back to the  
design patterns of 1999 - especially given the known problems that entails  
which I tried to explain above.

> or
>   <a href="url">Transcript</a>

You can still do that. In the worst browser, it will make no difference,  
but it seems likely that the best browsers will aim to provide something  
better if they get something more than that. At the very least, it is  
pretty straightforward to write an extension to handle more useful  



Charles 'chaals' McCathieNevile  Opera Software, Standards Group
       je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Wednesday, 23 May 2012 20:31:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:28 UTC