Re: Change Proposal for Issue 194

On Wed, May 23, 2012 at 9:31 PM, Charles McCathieNevile
<chaals@opera.com> wrote:
> 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.

I don't think so.

> This advice is all over the web, and it leads to the content not being available. You've
> effectively deleted it

"effectively deleted it" is a _radically_ different problem to "gain
keyboard focus".

Sylvia's complaining about a case where authors _try_ to effectively
delete things but fail!

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

I agree in a sense.

Out of the tiny segment of authors who think about a11y at all, a lot
of them seem to incorrectly conflate a11y with providing additional
hidden text for totally blind screen reader users.

This isn't the same thing of a11y provision, and 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.

I do not believe most publishers who produce transcripts really want
to hide even a link to those transcripts.

But, accepting _for the sake of argument_ that some publishers do want
to both produce transcripts and hide them from typical visual browser
rendering, I'm questioning the claim that hidden links inevitably pose
an additional accessibility problem beyond relying on browsers to
surface UI for hidden transcripts.

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

The comparison's not far-fetched, but I come to an utterly different conclusion…

<video> supports fallback to a simple link (yay!):

<video src="whatever"><a href="whatever">Video</a></video>

<transcript src=""> does not.

All things being equal, we should provide features with good fallbacks
in the style of <video>.

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

I think someone will need to explain them a bit more. ;)

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

Yes - that's more or less my point. The above works, and can be made
better in shiny new browsers, so why not use it?

--
Benjamin Hawkes-Lewis

Received on Wednesday, 23 May 2012 21:12:49 UTC