W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 1998

Re: alt-text authoring guidelines

From: Alan J. Flavell <flavell@a5.ph.gla.ac.uk>
Date: Fri, 10 Apr 1998 13:02:30 +0100 (BST)
To: Liam Quinn <liam@htmlhelp.com>
cc: w3c-wai-gl@w3.org
Message-ID: <Pine.OSF.3.96.980410120147.5106A-100000@a5.ph.gla.ac.uk>
On Thu, 9 Apr 1998, Liam Quinn wrote:

> For "Images and Image maps" (section 2.1--the first one), the first
> paragraph is great, but the examples in that section don't agree with the
> advice.  ALT="XYZ Logo" does not represent the function of the image; it
> represents a description of the image.  ALT text representative of the
> function of the image might be "XYZ" or "Welcome to XYZ", depending on the
> context.

I support Liam on this issue.

> Section 2.1.1 recommends using ALT for APPLET and INPUT.  I don't think ALT
> should be used with APPLET since alternate content can be given more
> effectively as the content of the APPLET element, allowing full markup
> whereas ALT text is limited to plain text.

I recalled that the APPLET content was meant to be displayed on client
agents that didn't support the APPLET, whereas ALT text was meant to
be used, in supporting client agents, while the APPLET was being
loaded. However, I see no evidence of this distinction in the HTML4.0
spec, and it says that the content is to be used both on
non-supporting client agents and on client agents that are capable of
supporting it but the option is currently disabled (these are two
rather different situations in my opinion, and arguably might call for
different handling). 

And the concrete examples in the 4.0 spec are pretty dumb as far as
the wording of the APPLET content is concerned.  What the heck is the
point of the words "Java applet that plays a welcoming sound" on a
client agent that doesn't support Java applets?  It might better say
something like "Hello, good evening and welcome", substituting the
_function_ of the APPLET, in preference to describing that function. 
I.e the principle is again the same as Liam was stating for IMG ALT.

(re. the section that should be numbered 2.3):

> LQ::  There is no ALT attribute on the MAP element.  Substituting "IMG" for
> "MAP", the advice seems to suggest ALT text of the form "See text links
> below".

("Later" or "next" or "shortly" might be less presentation-specific
terms than "below"). 

Yes, I feel that this paragraph needs reworking in a number of
respects.  I'm not quite sure what the document has in mind when it
posits a situation "When a server-side image map must be used", but
let's assume for the moment that such situations exist. 

If a simple list of text links can do an adequate job, then one might
wonder why the imagemap is there anyway; if a simple list of text
links _can't_ do an adequate job (example, a public transit map) then
I'd propose offering a genuine alternative means of navigation, such
as an A-Z index or a search engine - something that can be a useful
feature for all readers, irrespective of whether they're able to use
the imagemap.  And then there is no longer any need for, nor point in,
providing a simple (but long and unmanageable) list of text links. 

To sum up, I'd want the recommendations to say e.g "where a server
side imagemap must be used, then authors should provide some viable
alternative means of accessible navigation.  That might be a simple
list of text mode links - on the page or on an alternative page - or
might be an additional A-Z index, search engine, or whatever is
appropriate for the situation."

This last sentence in the paragraph: 

| To avoid confusion, if an alternative list of links follows the
| image map, authors should indicate with the "alt"  attribute of the
| MAP element that there is an alternate list and its location. 

seems to me to be quite confusing and unclear.  Either it should be
reworded, or a good concrete example provided of what is meant by it.

(I agree with Liam's further comments at this point, but for brevity
I'll omit them).

At this time, where support for TITLE (whether on IMG or on enclosing
A anchor links) is still only partial, I think we need to keep keenly
in mind both the ideal principles for usage of ALT and TITLE, as well
as the actual results that are likely across reasonably-current
browsers.  This inevitably involves some temporary compromises. 

> For the TITLE attribute, I think the best and most natural way to use it is
> to provide a title for the IMG, A, or whatever element. 

The ideal is that TITLE for IMG is a property of the image itself; if
the image is acting as a link, then the place for the TITLE of the
link is not the IMG - it is the enclosing A anchor link.  In practice,
for now, we have to compromise on this, bearing in mind the mutually
incompatible behaviour of browsers such as MSIE and Opera. 

In the "Invisible images" section, I think you need to distinguish
between null alt-text (i.e ALT="") on the one hand, and white space
(ALT=" ", or possibily in some situations even something like
ALT="&nbsp; &nbsp;") on the other hand.  In this context, your example
is of white space, which seems the right choice - your description
should reflect that. (I think the term "empty text" would be ambiguous
and best avoided).

Please take this as constructive criticism - clearly a lot of hard
work has been put into producing this document, and I don't for a
moment intend to decry that. 

All the best.
Received on Friday, 10 April 1998 08:02:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:27 UTC