Re: [Lynx-dev] @longdesc support in Lynx

[Leif Halvard Silli]

Thorsten Glaser, Wed, 13 Oct 2010 11:50:29 +0000 (UTC):
> Thomas Dickey dixit:
> 
>> So - it's a link, to someplace, and the guideline says it's not to 
>> be followed
>> as if it were an href.  So that leaves inline display, or some special
>> keystroke.
> 
> No idea. The XHTML/1.1 DTD says:
> <!ATTLIST %img.qname;
>       %Common.attrib;
>       src          %URI.datatype;           #REQUIRED
>       alt          %Text.datatype;          #REQUIRED
>       longdesc     %URI.datatype;           #IMPLIED
>       height       %Length.datatype;        #IMPLIED
>       width        %Length.datatype;        #IMPLIED
>> 
> 
> So it’s still allowed and, apparently, of same type as src.

The point in HTML4 is simply and only that even when there is an anchor 
element wrapping around the <img> element, the @longdesc link should 
still be possible to access. As we know, in regular graphical user 
agents, this is not possible. There can in principle only be one anchor 
element wrapper per element. If you add more anchor wrappers, then a) 
it is illegal, b) typically only the outermost anchor element is 
accessible to the user.

Another consideration that HTML4 cater for is that the presence of the 
longdesc link shall not "disturb" those who are able to "read" the 
image - to be presented with a link to a document which simply repeats 
the content of the image, could be confusing/annoying. Opera and iCab 
thus have special context menu which says "Link to description" or 
"Long image description".

But HTML4/XHTML1.* do allow you to nest links if you use an image map:

<a href=link> <img src=* alt="Lorem ipsum." usemap=#map > </a>
<map id=map >
  <area alt="1st link" href=another-link >
  <area alt="2nd link" href=yet-another-link >
 </map>

Practically speaking, there are 2 links nested in the anchor element. 
It might be that this would not work well in absolutely every Web 
browser. It might also be somewhat confusing. But at least it works 
relatively well in text browsers - primarily (I think) because text 
browser operates much more per-character than a graphical browser does. 

Additionally, Lynx, Elinks etc have a special way of dealing with 
<area> links of image maps: when you press the Right-Arrow key to 
activate the link, instead of going to any of the links in the image 
map, you get a list of the links you can visit. This behaviour already 
- to me - is a "special keystroke". 

It would be much or the same issues for @longdesc. And this why HTML4 
says that the longdesc link should be access in another way, so as to 
not confuse the user or "steal attention" from the anchor link.)

I just asked a day-to-day and WWW tech savvy screen reader user, who 
tested my @longdesc immitation at 
http://malform.no/testing/longdesc/address@hidden, and he 
agreed that it would be a good way to implement @longdesc if it worked 
as a simple image map.

PS: HTML4 also has @longdesc on the iframe element. The purpose is to 
allow you to read a document which explains the content of the iframe 
element. I have not, I think, tested iframes with text browsers. But I 
imagine that it would be good to have support for @logndesc there too. 

(Sorry, to repeat some of my points ...)
-- 
leif halvard silli