Imagemaps can be classified into two categories, depending on whether the results are evaluated at the server side (the original design) or at the client side. The client-side map has much to commend it, and current browsers may be expected to support it; but for relatively little trouble you can still provide server-side fallback for users unable to use a client-side map. For details, may I refer you to my own imagemap tutorial.
The now widely-available client-side imagemap is based on an original design that was set out in RFC1980 (originally due to Spyglass). Note however that reference to an external imagemap is not universally supported: as is hinted at in the HTML/4.01 definition of the usemap attribute, although not very clearly spelled out, the associated map is expected to be found within the same document, rather than maybe held in a common shared file where it could be referenced from multiple pages.
One shortcoming of many tutorials (and of some imagemapping tools!) is a failure to mention that the AREA tag supports an ALT text, which is intended to be used for constructing text-mode menus (analogous to the ALT attribute of the IMG tag). This attribute is mandatory according to the HTML4.0 recommendation, and rightly so, as it can provide a valuable alternative for text-mode users: Lynx (recent versions) will use it, and so will emacs-w3, as examples.
When a client-side map is used, most of the objections to the use of imagemaps go away: there is no problem with extra network transactions, and no problem with caching, and (with the browsers that I have used, at least) the user can always check where a link would take them before they decide to take it, so this takes out the "lucky-dip" problem of the server-side map. Apart from the issue of designing the imagemap well, so that it appeals to your readers, the only remaining problem is the frequency with which so many authors use images of text: you want that the reader should transfer umpty kBytes of data across the network as a separate data object, when a couple of dozen bytes of text added to the HTML data stream would have done the job just fine. Where the imagemap really comes into its own is when text could not have done the job "just fine": for example, where the user needs to make a selection from a geographical map or analogous presentation.
So, imagemaps play a role that cannot directly be substituted by anything else (for geographical maps, for example); but some alternative means of navigation such as an A-Z index or a search engine can be useful to all kinds of users, you should not devalue it as an extra chore that's only for text-mode readers.
It is still worth talking about text-based users (those who are unable or unwilling to load the actual image that belongs to the server-side imagemap): this affects not only those using text-mode browser versions prior to the introduction of client-side imagemap support, but also those using graphical browsers with image loading off.
For the server-side imagemap situation, there's what could have been an instructive Note at the W3C discussing the relevant issues for text-mode access. That note recommends that text-mode browsers should not send any x,y co-ordinates when a server-side imagemap is used; but the recommendation has been widely ignored in practice.
You could provide a discreet text-based navigation bar, for example, in which case, Henry Churchyard suggests coding ALT="" to hide the imagemap: this works in Lynx for a pure server-side map, but see the results tabulated at the end of this section; and emacs-w3 behaved differently again, and anyhow, there is no guarantee that this behaviour will be the same for all browser versions.
Text-mode browsers will do one of two things when a user selects the imagemap IMG's ALT text: some will send the URL without x,y co-oordinates, while others will send the co-ordinates 0,0. Ideally, your server's imagemap evaluator should do something sensible with either. You could arrange that the co-ordinates 0,0 are included in an area that takes the user off to a text-based navigation page. Even a 1x1 rectangle based on 0,0 would do the trick, although, if you are planning to use the same imagemap design for both client-side and server-side maps (imagemap tools typically make it easy to generate both kinds of map from the same design), it might be less confusing to users in general, if you provide a normal-sized map area based on 0,0 for this purpose, that's available for all browsers to use {ack. to J.D.Baldwin for making this suggestion}.
Another variation would be to have the default area (including 0,0) go to the text menu. There really does not seem to be very much benefit in doing what some authors do, and making the default area return an error report "you clicked in the wrong place", or returning status 204 (no action) whenever a text-mode user tries to use the imagemap: surely it's better to do something constructive like going to a text-based menu?
Please check out the server that you use, to find out what its imagemap evaluator does when invoked without any co-ordinates. Some of them will generate an error report to the user, rather than doing anything productive.
The imagemap evaluator that comes with Apache already does something useful - it responds by constructing a useful text-mode menu page based on the server-side map file. Good work! (See the Apache documentation for mod_imap for details.)
For those with such less-functional imagemap evaluators, by now (Spring 1997) you might consider it an unnecessary fuss to do anything fancy (most users will be able to use the client-side map, after all); but if you (or your server admin) are willing to "do the right thing" for those users, here's a pointer to a better version of imagemap.c offered by Joe Creighton at Univ. of Manitoba.
If, however, you can't or don't wish to get this fixed yourself, there's still that idea of having a separate text-mode nav.bar for them, after all. Having done that, you might take a moment to consider whether that text-mode nav.bar wouldn't really be a perfectly effective tool for all kinds of user, instead of going for the extra size and complication of an imagemap. I'm not saying that the answer should be yes in every case, but at least do take a moment to consider it.
An alternative solution would be to supply a client-side map for those that can use it, but drop the server-side function and just let the image (or its ALT text) act as a normal link, that goes to a text-based navigation page. This and other fallback options are also discussed in the RFC1980, which is well worth reading for oneself.
Different versions of Lynx have tried various strategies for displaying imagemaps. In addition to supporting the ALT= attribute on the IMG tag, some versions also do creative things if the TITLE= attribute is present on the IMG (note that in versions of HTML up to and including 3.2, the IMG didn't officially have a TITLE= attribute). On the version of Lynx (2.7) that was surveyed, the ALT text was basically used as a substitute for the image display, as usual of course, and the TITLE, if present, was used for titling the menu that represented the client-side area map.
Again considering only 2.7 that was reviewed in detail, the effect of coding ALT texts was as follows; there is no guarantee that this would remain the same in all versions, of course.
Server-side Client-side Both
(ISMAP) (USEMAP=) (ISMAP USEMAP=)
----------- ----------- ---------------
no ALT [ISMAP] [USEMAP] [ISMAP]-[USEMAP]
ALT="text" text text [ISMAP]-text
ALT="" (nothing) [USEMAP] [ISMAP]-[USEMAP]
As you see, it was only the pure ISMAP that was able to be hidden by coding ALT="": the other combinations always showed something. Furthermore, the dual clientside/serverside map always showed [ISMAP] no matter what texts were provided. I don't suggest you should specifically "design for" Lynx users - designing "for" one specific browser is usually a mistake, and this seems to be no exception (and there are other text mode browsers, emacs-w3 for example) - but at least it's useful to be be aware of the kinds of things it can do, so as to avoid the obvious traps like ALT="Turn image loading on!!!" that have been seen on the WWW. Hint: use these attributes to describe the resources that you are offering, not to second-guess what the user might or might not want to do with those resources.
Original materials © Copyright 1994 - 2006 by A.J.Flavell