Re: More about <alt> (was Re: Investigating the proposed alt attribute recommendations in HTML 5)

2007-09-05 04:10:07 +0200 Sander Tekelenburg <st@isoc.nl>:
> At 01:09 +0200 UTC, on 2007-09-05, Leif Halvard Silli wrote:

[ … why @LONGDESC]

>> With @ALT, we can do both a @ALT text and a @LONGDESC for the same IMG.
> 
> Well, my impression is that we can, only because both @alt and @longdesc
> exist... Why exactly do they exist at all? […] No such problems exist with <object> […]

The advantage of @LONGDESC is that it has a special purpose.

Also, it is fair to be able to choose between long and short equal content in some cases.
 
> Considering all that, is there really a need for both a short and a long
> equivalent? And if so, is there a need for them to be indicated semantically
> as such? (Remember that until now, HTML specs haven't made any such claim.
> @longdesc has only been defined for <img>, <frame> and <iframe>.)

I mentioned something in one of my replies yesterday: namely, if you have an photo album, which links to different sizes of each image, why not have an extra LONGDESC/@LONGDESC link that links directly to an authorative description of each particular image? That way e.g. unsighted and text users do no have to click themselves through unlimited levels and size versions of the same image. And also, Flickr or whatever would not need to have the same, long, ALT text on all pages for all images.

However we could achieve this in 3 ways:

<a rel="longdesc" href=">
<longdesc href="">
<img longdesc="">

[…]
>> <alt for='img' ><a href='longdesc'>My Cat</a></alt>
> 
> Well, authors still *could* provide long and short textual equivalents. They
> would only not have a way to mark them up in a way that non-humans would
> recognise them as such:

Yes they could - but it could still serve a purpose to have a special method for doing so - se above.

[ … @TITLE …] 
> Well, only if <alt> can be expected to immediately folllow <img>.
> 
>> Plus one would get to see the img @TITLE via tool tip for free Š ;-)
>
> Well, that in itself should be solved anyway, now that the spec says that UA
> must present @alt and @title differently.

;-) Yeah. So you mean we don't need to think about how it technically could be solved? The ALT element could just solve that technical problem though.

[ … compatibility issues …]

>> But, with <ALT>, all images would in fact lack @ALT text - so if we have
>> 
>>  <a href="ref"><img src="Inside_A"></a>
>>  <alt>Outside_A</alt>
>> 
>> Š then there would be no text link in text mode. Of course, one could add
>> @FOR, but I think this would be one case where many would err.
> 
> @for is required on <alt>, so a validator would flag this.

OK. I very much like the idea about ALT - the more I think about it. But I wonder about backwards compatibility. I think some special case issues needs to be solved for the IMG element. Maybe we need to allow @ALT and @LONGDESC on IMG. In that regard:

1) how about using @LONGDESC to point to the <ALT> element?
2) what about this special IMG case construct - i.e. keeping the IMG inside the ALT:

 <html><p><alt><img alt=""></alt>

 Then an AT UA would not be able to skip the text of the <ALT> element. And the empty @ALT on the IMG would make sure that we do not get any «double» alt-text whether in the GUA or the AT UA. The only drawback would be that it perhaps became difficult to find a bug free way of hiding the <ALT>-element but keeping the IMG element visible?
-- 
leif halvard silli

Received on Wednesday, 5 September 2007 03:05:26 UTC