Re: My case for the obsoletion of longdesc (Was: 48-Hour Consensus Call: InstateLongdesc CP Update)

Charles McCathie Nevile, Sat, 15 Sep 2012 16:53:50 +0200:
> On Sat, 15 Sep 2012 11:29:48 +0200, James Craig wrote:

James: I would suggest to combine @longdesc with iframe. See below.

But first: May be, if link focus worked better in Safari, you would 
have taken another tone? ;-) Because, while a curb-cut is elegant, one 
should not love the curb-cuts so much that one produces wheelchairs 
that are incompatible with stair lifts. That would  seem very dumb. And 
in that regard: It is OK to argue that something other than @longdesc 
wold work better. However, due to bug 22261 - "Clicking on a non-text 
input element does not give it focus",[1] Webkit and Chromium suffers 
from the following: if one opens a longdesc link (e.g. with Webkit 
based iCab) VoiceOver will start to read from the top of the page 
instead of from the section where the particular longdesc was situated. 
Something which takes away lots of flexibility with regard to longdesc. 
And, in fact, it also impacts regular links as well - it is is real 
hole in VoiceOver and Webkit's elegance.

>> To the best of my knowledge, one of these approaches (the iframe 
>> example listed at http://cookiecrook.com/longdesc/iframe/) works in 
>> all major implementations today, which is to say that it is much 
>> better supported than longdesc itself.
> 
> There are several issues that this approach does not solve.
> 1. It fails to improve on the "separate but equal" aspect of longdesc

Charles, is this about the short and long alternative text distinction?

> 2. It is actually available to fewer people - in particular, users who
>    have some residual vision, and benefit from at least looking at the
>    image, have no means to access the description.
>    Try magnifying your example by 500% and turning on high-contrast.
> 3. It requires starting from scratch to teach a new technique to authors,
>    educators, users, software developers.

But why not combine <iframe> with @longdesc? Roughly so:

   <style>#iframe:target{display:block}</style></head><body>
   <img src=i alt=text longdesc=#iframe >
   <iframe id=iframe hidden="" src=description.html ></iframe>

Demo page tested in JAWS+Firefox, JAWS+IE8, VoiceOver and iCab:

http://malform.no/testing/a-demo-of/longdesc-with-hidden-iframe/

Positives about pointing @longdesc to iframe with long description:

 1. Nothing new to learn w.r.t. longdesc.
 2. Possible to target browsers without longdesc support (a
    real concern if one read browser stats)
 3. Forward compatible with the recently specced requirement that
    hidden="" elements should be revealed at user request if 
    referenced via hash name or idref.

Negative: Must learn to use @hidden + a little CSS. (However, this is 
just *one* way to use @longdesc - it is not the one and only way to use 
it.)

A similar variant would be if the @longdesc pointed directly to the 
description page. However, then there would be no hash name link or 
idref link between <img>  and <iframe>. And therefore, only use of this 
second method would be as a workaround for Webkit. Example:

   <style>CSS to unhide iframe from Webkit/Chromium</style>
   <img src=i alt=text longdesc=description.html >
   <iframe id=iframe hidden="" src=description.html ></iframe>

[1] https://bugs.webkit.org/show_bug.cgi?id=22261 
-- 
leif halvard silli

Received on Sunday, 16 September 2012 02:56:33 UTC