Tooltips and alt texts for image maps
HTML authors often ask how to make browsers show
"alternate texts" for
image map hot spot areas.
What they typically mean is how to make browsers show
those little popup windows with short texts, "tooltips",
when the cursor is over an area in a (client-side) image map.
The reason is that authors have noted that
"tooltips" appear for normal images (img) elements when
they have alt attributes, and they may expect
the same to happen for image maps, but often it won't.
This document tries to clear up the confusion, explaining
what alt attributes are really for; it also
discusses various ways to create "tooltips" (on some browsers).
Content
There are two kinds of
image maps: server-side and client-side. This document discusses the
latter only.
A client-side image map is an image where some areas have
been designated as "hotspots" which refer to some documents,
in a manner similar to normal links.
(They could also refer to specific locations in documents.)
The areas can be rectangles, circles, or polygons; using
sufficiently many vertexes, a polygon can approximate a connected
area of any shape.
In simplest cases, an image map could be constructed "by hand",
using just some tools like a general image processing program
to determine, say, the coordinates of a rectangle. But for
irregular shapes and for image maps with a large number of areas,
it becomes awkward. There are nice
tools for creating image maps,
such as
MapThis
(freeware) and
MapEdit (cheap).
(Using such a tool,
you can start from an image file, or an HTML document containing just
an img element referring to the picture
that should be made an image map.
The tool then lets you specify, in a graphic user interface,
the desired hotspots, and what they should link to, as well
as alt (and perhaps title attributes).
Depending on the program, it might then
modify the HTML document by adding the markup needed, or just
generate the map element needed.
So a client-side image map per se specifies that some areas
of an image are links to something.
This is great for a picture of a group of people,
to make their heads links to their home pages for example,
or for a geographic map,
to make each country or state a link to a document that tells
something related to the area.
But displaying textual information
on the same page as the image map is more difficult.
And quite often it would be important to display some textual
information when the user is about to click on an area,
e.g. to show the person's name or country name.
Some browsers may
display the alt attribute value
or the title attribute value
for an area as a "tooltip".
And in some situations, you might consider the "tooltips" as
the real thing (and use dummy
href references, i.e. the areas would not really be links).
But then your real thing would be inaccessible to a considerable number
of users. You might additionally use JavaScript
to display the texts on the page,
and this document briefly explains how,
but even then you cannot rely on any texts appearing.
It depends on the intended application how serious this is.
Normally you should make a set of textual links available,
along with the image map, to ensure universal accessibility to the
information.
The meaning of an alt attribute, as defined in
HTML specifications, is to define a textual alternative
for an image (or, more generally, for some element in HTML).
There is a very common confusion in this issue, created by popular
browsers' way of using alt texts as "tooltips" too and
implementing the defined meaning in a rather poor way. See my
document on alt attributes for
img elements for a detailed explanation.
You should use an
alt attribute in the img element to specify the
alternate text for the entire map,
and an alt attribute in each area
element to specify the alternate text for that area. You should do this
independently of whether you need the alternate texts or not; the
alternate texts are for those visitors who do not see the
images.
For example, a speech-based browser can be expected to
read the alt
attribute value of the image, then the
the alt
attribute values of the area elements in the order they
appear in HTML source. This is not guaranteed, but it is a reasonable
expectation. Consequently, you should use order the
area elements in an understandable and manageable way.
If there are just a few areas, the order does not matter much, but
if there are many of them (like the states of the US, or major parts of the
human body), an alphabetic order is usually the best.
Some browsers do not support alt
attributes for area at all, in the
defined meaning of those attributes. Sadly, this applies to most
graphic browsers (at least the versions I've tried), such as Netscape,
IE, and even Opera. On such browsers, the entire image map construct
can be useless if the image is not displayed.
If the image is not displayed, for some reason or another,
a generic symbol or an empty box is displayed instead,
with the alt for the image. There is no indication
of there being anything selectable, anything useable.
Before you say that this is nothing to complain about,
consider the fact client-side image maps can well be written to
work in text mode too and they do work in text mode,
if properly written, as the Lynx browser demonstrates.
After all, an image map is effectively a collection of links,
just with areas of an image instead of link texts, and if you specify
textual alternatives to the areas, a browser can implement it as a list
of links. And there is a large number of
reasons why
a graphic browser might not display an image.
Several popular graphic browsers
even fail to support the alt attribute for an
img element which specifies an image map,
if that element has width
and height attributes such that
the alternate text does not fit into the
box allocated for the image! This problems exists e.g. in
the Windows versions of Netscape 4.0 and IE 4.0, but it seems to
have been fixed in Netscape 4.7 and IE 5.0.
Let us assume that you have some pages containing information
on some fruit. The pages might be your commercial pages on
your fruit products, or scientific research reports
on the properties of fruit, or your fruit food recipes, or whatever.
In my example, the pages give information about nutritive values
of fruit, in Finnish. (No, I don't assume you know Finnish; there is
a point in using an example with pages in a strange language.)
The following images of fruit are links:
![[Apple]](../images/apple.gif "apple")
![[Kiwi fruit]](../images/kiwi.gif "kiwi fruit")
![[Pear]](../images/pear.gif "pear")
Source of the images:
Free Food Clipart from Don's Kitchen, address
http://www.donskitchen.com/clipart.htm
(now removed).
Whether you use links as images that way, and how you do that,
is a many-sided question.
In the example above, the images have (on most browsers) borders
around them, with the border color indicating whether the user has
(recently) followed the link or not. It is one of the controversies
whether an author should try to suppress the borders (which
is technically easy) or to let them be there.
In a sense, you have usability against esthetics; my advice is that if
you prefer esthetics, make it otherwise very clear to readers
that the images are links.
See my
Links Want To Be Links, which generally recommends using
simple textual links, but see also
my notes on using
images in communication.
Sometimes images greatly help,
especially when there is something inherently visual involved.
An image of a fruit, a good image at least, is more widely understood
worldwide than the name of a fruit in any particular language.
In that sense, images could increase accessibility.
In our example, the links point to textual information, but the
tabular data there could still be partially
understood by someone who doesn't know the language used.
"Energia (kJ) 172.0" isn't that hard to decipher, is it?
And in the general case, the document at the end of the link could
be inherently visual too, like a collection of photos of fruit trees
or fruit varieties.
But our topic is image maps, so let us consider the image map alternative.
You could use a single image and make its parts hotspots. In
my trivial example, I have just combined the three separate images into
one; in a more normal case, you would start from a single image,
such as a still life painting or photo. And
using an image map you could make the parts of the image any
shape you like, not just rectangular. My
example uses
rectangular areas only
for simplicity. For such areas, you don't even need any special
tools for constructing an image map; you just determine a few coordinates.
In the general case, you would use polygons to specify areas, and then
you would in practice need some special
image mapping software.
But these interesting issues are not essential for our discussion of
alt texts and popups, so I use a simple example:
The markup used is essentially the following:
<img src="..." alt=
"Select a fruit to get information about its nutritive value"
usemap="#fruit" ... border="0">
<map name="fruit">
<area href="..." alt="apple (omena)" coords="0,60,92,160">
<area href="..." alt="kiwi fruit (kiivi)" coords="0,60,92,160">
<area href="..." alt="pear (päärynä)" coords="0,60,92,160">
</map>
On a graphic browser when the image is available, the image map
works more or less similarly to a set of image links. You can click on
areas of the image, just as you can click on individual images.
There are differences however, party browser-dependent:
- There is just one image, as opposite to a set of images, some of
which might be displayed and might arrive at different times.
This however isn't very important in practice.
- Areas in an image map can have any shape. An individual image is
a rectangle, though it may have transparent parts
or parts with the same color as the background
which can make it look
non-rectangular.
- There's nothing that displays any borders for the areas
unless you make them part of the image itself. With separate images,
you have the option of making them bordered using HTML or CSS.
- Browsers' behavior on mouseover may differ, and it's generally
more informative when separate images are used. The
"tooltip"
effects are often confusing for image maps.
On the text-based Lynx
browser, the user would then see the text
Select a fruit to get information about its nutritive value
in a manner that suggests (to Lynx users) its being link-like,
and following the link the user would get this menu:
Select a fruit to get information about its nutritive value
MAP: http://www.cs.tut.fi/~jkorpela/html/fruit.html#fruit
1. apple (omena)
2. kiwi fruit (kiivi)
3. pear (päärynä)
The details vary according to Lynx version, but in any case,
it would work quite nicely - about as nicely as it can work without
the images.
But what happens on graphic browsers when the image
is not displayed, for some reason? Here's what your current browser does
when the image referred to by the src attribute is
nonexistent,
first in the case where the image has width and
height attributes, then in the case where
it lacks those attributes:
In the first case, e.g. Netscape 4.0 does not show the alt
text, for some odd reason.
For further oddity, Netscape 6.1 behaves the other way around.
Note that this experiment may differ from what you get when you tell
a graphic browser not to show images.
For example, if you disable images on Netscape 6.1,
the alt texts are not shown at all.
More exactly, this was tested on Mozilla/5.0 (Windows; U; Win98;
en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 in no images mode, which
was selected as follows:
Edit >
Preferences > Privacy and Security [!] > Images,
check "Do not load any images".
In any case, the "image map" is a mystery
to users. There's really nothing that suggests what the alternatives are.
Well, perhaps the URLs that may get displayed in the browser's status line
could sometimes give a clue - though not in our example.
In the first case, the areas are there, and clickable,
but the areas are not indicated and there are no explanations
(except, perhaps, upon mouseover).
In the second case, it's even worse, since
graphic browsers seem to behave so that some parts of the
rectangle react to clicking, in a very confusing way.
Wouldn't it be frustrating if textual information
is unreachable if an image used for accessing it is not available?
The problems of
graphic browsers with image maps in no-images mode
are a good reason
to provide a separate textual menu
as an alternative to the image map.
(Funnily, quite
often authors think that non-graphic browsers would have
problems with image maps; this gets the situation upside down, since was we saw,
text-only browsers like Lynx can handle properly written
image maps just fine.).
Select a fruit to get information about its nutritive value
either by clicking on its image or by selecting from the following menu:
A good text-only browser effectively presents an image map as a "menu",
a list of links
that uses the alt attribute values as link texts. Of
course, it also displays a separate textual menu if specified on the
page. This looks a bit foolish,
but the importance of helping
people that use alt-challenged
browsers probably outweighs the drawbacks.
Any duplication of menus is somewhat confusing to users,
but it helps to make it clear (rather explicitly)
that the textual
menu is an alternative to using clicking on an in the image.
Often you can put the image and the textual menu side by side
(e.g. into a table) to emphasize this, as above; but this should only be done
if the image is not so wide (let's say 300 pixels at most)
that difficulties would arise in narrow browser windows.
Note that the image map and the textual menu should be as
similar in structure (isomorphic) as possible, with
items in the same order, unless you make it explicit that
there is a difference. For example, if the image map presents the US states,
the textual menu could list them in alphabetic order. This will not
correspond to any visual order in the image map, but you can still
write the area elements into alphabetic order by state!
The ordering of area elements inside a map
element is almost always
irrelevant as far as graphic presentation is considered
(since it's the shape and coords attributes
that specify the visual position),
but it determines the order in which the items occur on text-based
browsers. (For completeness, we need to remark that the order matters a lot
in graphic presentation if there are overlapping
areas.) And try to use the same texts in the textual menu as
in the alt attributes, so that it is evident
at a glance that they are identical, when they are both seen.
There's still the inevitable problem that for any
duplication of menus, the user may start wondering whether they are
really the same. Too often we find duplicated menus which aren't
quite the same; some items might appear in one menu only, so to check
what's really available, the user would need to check both of them.
And when this has happened often enough, it becomes a habit to the user
to be suspicious about apparent duplicates.
Using a "redundant" list of textual links along with a client-side
image map, as suggested above, solves a problem with
search engines too.
When a search engine collects information into its data base,
to be used in searches, it basically processes Web pages by scanning
their textual content and following links in order
to find new pages to process. Although different search engines
do different things in addition to such processing, the basic "food"
for search engines are normal text and normal
links (<a href> elements)
in the document body.
Search engines might process
area elements on the pages they have found,
treating the
alt attribute values as comparable to textual content
and using the URLs in
href attributes to find other pages just as they
use href attribute values in a elements.
But most of them probably don't.
See
Search Engine Features For Webmasters
at Search Engine Watch for a compilation of information
what some major search engines seem to do.
Thus,
using a list of textual links you make it much more probable
that search engines will
- process the names of the links when indexing the page, so that
the page can be found when searching for pages with those
words in the search clause
- follow the links to find the pages behind them (your sub-pages,
as a rule).
Some graphic browsers, like IE and Netscape 4
(but not Opera), in addition to
not using the alt attribute for area
for its defined purpose, use it
for something that it should not be used, namely as a "tooltip" text
for mouseover. Cf. to similar, though less serious,
clueless behavior in their
treatment of alt for img.
For further absurdity, IE 4+, despite mostly supporting the
title
attribute (in a primitive way, but still - Netscape 4
doesn't get it at
all), often ignores that attribute in
area (but not in img!), if the alt
attribute is specified there (and the alt attribute is of course
essential for accessibility, and even syntactically required by HTML
specifications).
Thus, for example, when you have a client side image map
and the user moves the cursor over the image,
- Netscape 4 seems to behave in confusingly
different ways. In some situations, it
displays as a tooltip
just the value of the
alt
attribute of the entire image (the
img element), no matter where the cursor is
inside it.
(Some tests suggest that this happens when the image map is not
initially visible in the browser window.)
Sometimes it has been observed to display
the alt attribute value for a rectangular or
polygon area but not for an
area with shape="circle"!
- Internet Explorer 4 and 5 may display some tooltips
for the areas. There seems to be variation between different
variants of IE: Some variants
display as a tooltip
the value of the
alt attribute for the
area element when the cursor is over a hotspot
(an area with a href attribute), and show
the value of the title attribute
instead, if the area
element has such an attribute and invalidly lacks an
alt attribute.
Other variants show the title attribute value
and ignore alt.
In other parts of the image than the hotspots,
IE generally displays the title attribute of img
if present, otherwise its alt attribute.
- Opera does not show any tooltips.
If "tooltips" are intended to be just additional hints,
it would be quite adequate to try to use
client-side scripting
for displaying them in various ways. You could associate scripted events
using event attributes. Basically you would use
the onmouseover attribute
for area elements and, if the
image map is accompanied with an equivalent set of links, with
a href elements.
But where would you display the hints? Using the browser's
status line is one possibility (using
window.status='string' in JavaScript), but
there are several reasons to avoid that; the status line is better used
for other purposes like displaying the URL of a linked document, and it
is not that easily noticeable by users. Among other alternatives, the most
widely supported one is using a text input field. You would
write a (dummy) form element
(lets say you have <form name="show">)
and
an element like <input name="foo"> inside it, and
just use something like
onmouseover="document.show.foo.value='string'"
in JavaScript.
This is clumsy in several ways, but it seems to work on all JavaScript-enabled
browsers. Note that we should make some reasonable attempt to
make the input field readonly, to try
to avoid confusing users who regard it as a real input field waiting
for actual user input.
The following simple example puts this idea into action. It uses
out fruit example, and this illustrates the example mentioned in
Webopedia's
article on image maps:
For example, imagine a graphic of a bowl of fruit.
When you click on a banana, the system displays the number of calories
in a banana and when you click on an apple,
it displays the number of calories in an apple.
Would you believe that I found that nice article and its example
after I had written my basic example of a fruit image map that
refers to nutritive information? Well, I did anyway.
By the way, my example uses a standard
(SI) unit for energy,
kilojoule (kJ), instead of calories; 1 kJ = 0.2388 kcal.
We modify our basic example so that in addition to letting the
user select a fruit and get the information, it immediately displays
one piece of information, the energy content, on the page (if
the browser is JavaScript-enabled).
This was of course just a simplistic illustration. In this case we
might have just as well put the energy content information along with the
textual links. But in a more realistic case, you might wish to display
more information on mouseover, perhaps updating several fields, or perhaps
using textarea element to display multi-line texts.
There are more advanced things that you could do using
so-called
"dynamic HTML".
See Martin Webb's article
Dynamic Floating Tool Tips
for a description of the ideas.
Using the nohref attribute in
an area element is the HTML way of telling that
the image area is not to be active.
An active area
is one to which some URL is assigned so that selecting
the area (by clicking or otherwise) causes transfer to that URL.
And active areas are really the beef in client-side image maps.
But you might wish to make some part of an image,
like the background, non-active.
Sometimes however authors want to make all areas
non-active. This sounds odd, and it might in fact often reflect
wrong design. Anyway the point is probably that the author
is using an image map only for the side effects
he expects them to have, probably "tooltips" of some kind,
as those discussed above, or some events specified e.g.
in onmouseover attributes.
One problem with this is that those side effects are all
optional and nothing to rely on.
And if you make an area non-active,
it might stop reacting to those optional events that are
the only reason for using an image map in the design discussed here.
Some browsers treat area elements as "real" only
if they have href attributes (instead of having
nohref or neither of these. Now you have a problem
if there's nothing real to be specified there. Some users might
still click on the area, and then the href value
will actually be used, even if it wasn't meant to be.
But there's a workaround. I don't mean the usual
approach of using the URL reference
"#"
(which means a reference to the start
of the current document, which is usually not what you want),
use a real URL reference which points to a suitable location inside
your document. Specifically, you could make the img
element of the image map a destination anchor and point to it.
Schematically:
<a name="themap"><img ... usemap="..."></a>
...
<map ...>
<area ... href="#themap">
...
This way, clicking on the area will take us to the image itself, which meansthat the image is positioned at the top of the browser window.
This should be acceptable -
or you might make the
href
point to something more suitable, like a heading right before the image.
On the other hand, if you rely e.g. on
onmouseover for showing some information, you exclude all non-JavaScript users. It might be better to make the
href attributes point to something real, such as locations on a separate page that contains the information to be shown.
Using image maps just as
decorated versions of sets of normal links is usually
a bad idea. Even if you use images for linking, a set of separate
images works better than an image map. But
if you have something that sufficiently resembles a real map
in the sense of being
inherently two-dimensional, and if its areas should work as links,
then it could make sense to make it an image map, despite all the
problems.
When using a client-side image map,
-
provide a separate set of textual links to the same targets as the
areas link to, and
make it clear that it duplicates the functionality of the image map
- for the
img element, write an alt attribute
that expresses the purpose
of the image map (and thereby works well when
implemented as a link text)
- for each
area element, write alt
and title attributes
that tell what the area points to, i.e. describes the content of
the document linked to; the values could be the same, or the alt
value could be an abridged version of the title value.
I have often criticized the use of
image maps for "navigation"
from the usability point of view, saying that they create
riddles, not useful tools. But here I present an image map
which is intended to be a riddle. The image here
is a photo of me as a baby. Guess whether there's any hot spot
and what it might do! This guesswork is essentially different on
different browsers, due to differences in their implementations of
the constructs used.