W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2001

Re: alt title and links

From: Alan J. Flavell <flavell@a5.ph.gla.ac.uk>
Date: Sun, 19 Aug 2001 15:31:00 +0100 (BST)
To: Jonathan Chetwynd <j.chetwynd@btinternet.com>
cc: WAI Guidelines List <w3c-wai-gl@w3.org>
Message-ID: <Pine.OSF.4.30.0108191457010.11308-100000@a5.ph.gla.ac.uk>
On Fri, 17 Aug 2001, Jonathan Chetwynd wrote:

> This does not mention links.
> If it is the case that alt should describe the image and title the link, do
> we need to state this?

Technically, the following parameters are available, in the situation
that I think you are describing i.e an image acting as an anchor link:

- the alt attribute of the <img ...>
- the title attribute of the <img ...>
     (the longdesc is also available, and
     important in its way, but I don't think
     it's what we're talking about here)
- the title attribute of the enclosing <a href=...>

What needs to be discussed, and I've never seen this done in enough
detail (and all the discussions I've seen have backed-off from
analysing what the principles _should_ be, out of consideration for
the presently-available implementations that people are using) would

a) how, ideally, ought these parameters to be used?

b) how, if these parameters were used ideally, ought client
agents to present them to the user?

It seems clear to me that the title attribute of the <a href=...> is
for supplying additional information about what is to be found at the
target of the link.  This information could meaningful for all kinds
of links, not only those which use <img ...> to implement them (and in
fact the title attribute of the <a ...> element has been a feature of
HTML since at least HTML2.0, long pre-dating the title attribute on
HTML elements in general).

The title attribute of the <img ...> would seem, logically, to be
available for providing a brief description of the image itself,
independent of the fact that this particular image is also serving as
an anchor link.

I guess my views on the alt attribute of the <img ..> are already well
known: the detailed wording of any recommendation gets kicked around,
but it's meant in general terms to serve as a text-mode _alternative_
for the _purpose_ of the image.

If the image was primarily there to convey information, then the alt
text should also be primarily there to convey that information.  On
the other hand, in the case where the image is primarily intended as a
decorative link to another resource, the alt text should be designed
to serve as a text-mode link to that resource, without diverting
attention to incidental features of the particular decoration that was
used (the img's title attribute is still available for that purpose).

Do the usually-available client agents co-operate with this view of
the intentions?  In general I think we'd have to say "no", or rather,
"only partially".  For example, of the various attributes, the <a
title=...> would seem to be of more importance to the user than the
<img title=...> in this kind of situation, but the popular client
agents will give the inner (img) markup priority over the outer (a
href) markup.  In fact if the img stands alone within the a href, then
it seems impossible to persuade popular clients to display the title
attribute of the a href, if the img also carries a title attribute.
Only when the a href element contains both an img and some normal
text, is it possible to see the title attribute of the a href - by
hovering over the text.

Sure, this is a description of the popular browsers, rather than of
specialised accessibility agents.  And for example with MSIE it's
possible for the user to supply their own persistent scripts, which
could analyze the document object and display features that are not
normally exposed to the user.  (The MSIE5 Web Accessories, IE5WA,
illustrate some examples of what is possible in this regard).

So, an admittedly unsatisfying and incomplete answer, but I hope it's
somewhat helpful, nevertheless.
Received on Sunday, 19 August 2001 10:31:08 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 16 February 2017 16:48:36 UTC