Re: Change Proposal for Issue 194

On Thu, May 24, 2012 at 7:11 AM, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com> wrote:
> 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.

It actually was. :-)
But I leave this discussion to Charles and John, who are much more
knowledgeable about hiding content than I am.


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

No I wasn't. I don't even know what that means.

>
>> - 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 don't either. Using an explicit <transcript> element actually
encourages publishers to keep their transcripts visible on page and
include them in their published content to the advantage of all users.


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

That's good news then.


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

This works, too:

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

and can be made even better in shiny new browsers than just the link alone.

Silvia.

Received on Wednesday, 23 May 2012 21:56:22 UTC