Re: More about <alt>

At 05:05 +0200 UTC, on 2007-09-05, Leif Halvard Silli wrote:

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

[...]

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

That in itself is just as much a disadvantage ;) It forces authors to make
the right choice: whether/how to use it, or @alt, or both.

> Also, it is fair to be able to choose between long and short equal content
>in some cases.

Sure, but the current <alt> proposal makes that entirely possible. It just
doesn't include a defined method to indicate short vs long textual
equivalents. It currently relies on authors indicating that through sensible
@title use...

[...]

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

Hm... You mean on a page with multiple different images, have a single link
to a single resource containing the equivalents for all those images?
(Doesn't seem like that would be very clear to users, or easy to author and
maintain.)

> That way e.g. unsighted and text users do no have to click themselves
>through unlimited levels and size versions of the same image.

They don't have to anyway. As I said in another message: <a
href="bigimage.jpg"><img src="thumbnail.jpg" longdesc="URL"></a>.

> And also, Flickr or whatever would not need to have the same, long, ALT
>text on all pages for all images.

You would still need all equivalents available from every size version of the
image, because you can't be sure that a user will enter your site through one
or the other door.

[... <alt>]

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

I can't follow. How *what* could be solved?

[...]

> OK. I very much like the idea about ALT - the more I think about it.

Excellent. Please sign the petition ;)

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

Compliant HTML5 UAs would then expose both @longdesc and <alt>. So two
pointers to the exact same equivalent. Users would be confused. Authors would
be discouraged to start using <alt>.

To avoid that, we would have to spec that UAs must recognise such cases, and
suppress @longdesc. But that might well be too much magic to expect them to
pull off reliably and interoperably.

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

Yeah, but what about HTML5 UAs that generally will show the image by default?
The idea is that HTML5 UAs do not present all equivalents (unless the user
wants that). So the idea is that authors/UAs/users can set <alt> to
display:none.

So an <img> embedded in <alt> would then also not be displayed.

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

Exactly... :)


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Thursday, 6 September 2007 14:06:20 UTC