Author’s note: This article explores server-side image maps, a historic web technology. In 2021, the use of server-side image maps is considered a worst practice. Hopefully, no one thinks I am encouraging the use of server-side image maps. Although they provide hours of fun for weekend hobby projects, they are an accessibility nightmare. Please don’t proliferate server-side image maps in real-world projects in 2021! OK, with that out of the way, let’s get started…

Setting the Stage

I realize that this is another unplanned change that I’m making without getting a consensus or having it added to the spec or whatever.

– Marc Andreeson, discussing the addition of server-side image maps to the Mosaic web browser, May 18th, 1993.

I recently found myself reading over a very old HTML spec and encountered something I had almost completely forgotten about- the ISMAP attribute for IMG tags.

The ISMAP attribute allowed prehistoric web developers to convert images to a “server-side image map”. What follows is a brief overview of my re-discovery of this amusing attribute.

In the year 1993, the web was young. There were no javascript onClick events, and in fact, there was no Javascript at all. CSS would not show up for another three years. Despite a narrow feature set, web developers were building an exciting vision of what the web could become.

In the case of server-side image maps, web developers of the era needed a way to create dynamic clickable graphics, and they didn’t have the luxury of Javascript or CSS. Creating an image hyperlink was already possible, but this only allowed one hyperlink destination per image. What if the image was a map of the United States, and you wanted to direct the user to one of 50 pages based on a single click of that image?

Another use case was the creation of intricate menus for web pages. Since CSS was still in its early days, web developers that wanted a way to build flashy graphics were limited in their options. One workaround that many web designers would deploy was not using HTML for the UI’s graphical elements. Instead, they would design the layout entirely as an image and write a server-side CGI script that could render a subsequent page based on the X/Y coordinates of the last point clicked on the image. This practice is now frowned upon.

Taking this example further, I decided to do some historical re-enactment. What would an interactive drawing app look like in the early 90s? I created this hilariously underpowered drawing app in one sitting last weekend to illustrate the point. The app does not use Javascript or CSS and allows multi-user interaction with a shared monochrome canvas (barely).

Digging Deeper

Advanced amateur Google research has led me to conclude that the ismap attribute was first added to the Mosaic browser in the early 90s, circa 1993. At that time, it was added as a non-standard feature.

Later, in November of 1995, the ismap attribute was referenced in RFC 1866, the HTML 2.0 specification. RFC 1866 is the first official standard I can find that references server-side image maps. If anyone can find earlier documents (official or otherwise), please leave a comment on Reddit or Lobste.rs.

Problems Presented by Server-Side Image Maps

Server-side image maps disappeared from use for a variety of (good) reasons. The most notable reasons are that server-side image maps are inaccessible to users who cannot use pointing devices or view images. Developers of the era were encouraged to provide clickable hypertext links with computer-readable descriptions alongside the image, though this was rarely practiced. The result was an inaccessible website.

Another argument against server-side image maps was that they are not offline-first, though I would argue that the days of being able to keep offline backups of a website are far, far behind us.

Later Refinements: Client-Side Image Maps

The accessibility challenges of server-side image maps eventually led to the introduction of client-side image maps in HTML 3.2.

Like their server-side counterparts, client-side image maps allowed developers to create clickable, interactive graphics on HTML documents. Unlike server-side image maps, the map information is entirely contained within the HTML document. This means that screen readers and text-based browsers can parse the data locally and provide an accessible alternative to the graphical image map. This assumes that the developer followed best practices, such as giving descriptive ALT text for each map region.

Client-side image maps are nested directly within an img tag using various tags that describe shapes for regions within an image. Since an image map tutorial is beyond this article’s scope, I will provide a link to an MDN tutorial here.

Below is a screenshot of a website hosted by Penn State that explains the accessibility aspects of client-side image maps. I’ve provided screenshots below showing how the image map renders in a graphical browser (Dillo) and a text-based one (Lynx). Because the image map was implemented correctly, I was able to extract relevant information from the image map, even in a text-based browser.

Rendering the page in Lynx, a text-based browser:

The same web page, rendered in a graphical web browser:

Image Maps Today

As stated previously, server-side image maps are discouraged in modern websites. On the other hand, client-side image maps are not a deprecated technology, but they are rarely seen on modern websites. I attribute this to the fact that Javascript has matured to the point that it can replace image maps with custom client-side code that is tailored specifically to the needs of the application.