Re: longdesc - beside the box

Benjamin Hawkes-Lewis, Tue, 26 Apr 2011 16:48:16 +0100:
> On Tue, Apr 26, 2011 at 3:32 PM, Leif Halvard Silli wrote:
>> Benjamin Hawkes-Lewis, Tue, 26 Apr 2011 13:55:58 +0100:
>>> On Tue, Apr 26, 2011 at 12:22 PM, Leif Halvard Silli  wrote:
>>>> Benjamin Hawkes-Lewis, Tue, 26 Apr 2011 10:16:32 +0100:
>>>>> On Tue, Apr 26, 2011 at 2:57 AM, Leif Halvard Silli wrote:
>>>>>> iCab does show a "default visual encumbrance" for images with
>>>>>> @longdesc.
>>>>> 
>>>>> The user has to take a special action (hovering over the image) to
>>>>> display the encumbrance (a cursor change), so it's not "default".
>>>> 
>>>> That's the same for many links: until you hover above them, you don't
>>>> see it is a link.
>>   [...]
>>> @longdesc is hidden metadata by design;
>> 
>> The 'Techniques for User Agent Accessibility Guidelines 1.0' from 2002
>> did not design it as hidden:
>> 
>> http://www.w3.org/TR/UAAG10-TECHS/guidelines#long-descriptions

> 
> No popular user agent presents a "forced visual encumberance" for
> @longdesc, and @longdesc's lack of a "forced visual encumberance"
> is a major plank in the rationale for making it conforming that
> has been presented to the WG.

"By design" was your wording - not mine. And popular user agents which 
do not implement @longdesc at all, do not count when we look at how it 
@longdesc "by design" operates.

As it turns out, only a single user agent, iCab, has a unobtrusive 
visual indication when there is a @longdesc. 

>>> hyperlinks and most aspects of
>>> microformats are visible data by design.
>> 
>> While, as you said, it is considered good to use underlining for links,
>> it is probably more important what happens with the cursor.
> 
> I disagree.

Noted.

>> Not least because links where the image is the sole content do not get
>> any underlining by default.
>> 
>> Thus an image that is a link is in fact (easy) discoverable meta data
>> and not visible data - by today's design.
>> 
>> (The blue frame around images disappeared because it was considered
>> ugly, but it can in fact still be seen on img elements with @usemap in
>> Internet Explorer [in some modes, at least].)
> 
> In practice image links tend to have visual traits that identify
> them as such long before you hover over them. An image is likely to be
> clickable if one of the following is true:
> 
>    1. It's a thumbnail.
>    2. It's got a play icon superimposed.
>    3. It's visually associated with a text link to an article.
>    4. It's presented as one of a list of images.
>    5. It's an icon.

Many images in need of longdesc will also invite to hover above it to 
see if something "happens" - either because its content looks 
interesting and yet not fully accessible as a image, or for other 
reasons.

It might even be that most images on the Web are links - which sets 
expectations. Nevertheless, testing whether a piece of text or an image 
is a link, is something I often do as a user.

> In so far as image links are indistinguishable from unclickable images,
> the encoding of the relationship part of their data follows the hidden
> metadata antipattern to their detriment.

An author will know - that's the most important part, that's what keep 
their links updated. Authors as well do not need much more than iCab 
provides in order to keep images with @longdesc updated.

>> Wether there by *default* should be visible indicator on the picture
>> itself - that's a detail that we still need to discuss more.
> 
> I think the debate about how to handle long descriptions in HTML is
> mostly about this question of whether we need to provide features
> dedicated to making them invisible. Much as with table summaries.

It would have helped the debate if more members of the HTMLwg could 
_see_ what we are talking about. For that purpose, I can only recommend 
iCab. :-)
--
Leif H Silli

Received on Tuesday, 26 April 2011 16:10:40 UTC