Server-side image map is used

What is this issue?

An <img ismap> element sits inside an <a href="..."> link. Clicking anywhere on the image sends the exact pixel coordinates of that click to the server as part of the request URL, and the server decides which page to serve back based on where the click landed. This is a server-side image map: a coordinate-based navigation pattern from the earliest years of the web, distinct from a client-side image map, which uses <map> and <area> elements that the browser resolves locally without any server round-trip.

Because the entire interaction depends on the coordinates of a physical click, there is no href on any specific, focusable target for a keyboard user to reach. The image itself is the only interactive element, and it has no way to represent “which region did you mean” to anything other than a pointing device.

Why does this matter?

Coordinate-based navigation has no keyboard equivalent by definition. Tab can move focus to the link wrapping the image, but pressing Enter there sends a click at coordinates 0,0 or whatever default the server happens to handle, not the specific region a keyboard user intended to reach. There is no way to express “the top-right region” through a keyboard alone when the entire mechanism is built around exact pixel position.

A campus website using a server-side image map to navigate between buildings on a visual map locks out anyone who can’t physically click a specific spot on that image, not just screen reader users, but sighted keyboard-only users, switch-device users, and anyone using voice control software that targets named elements rather than coordinates. Every one of these users hits the same wall: a link that goes somewhere unpredictable, or nowhere at all, no matter how they activate it.

Who is affected?

• Keyboard users: can Tab to the image map’s link but have no way to select a specific region once focus lands there, since the interaction is defined entirely by pixel coordinates a keyboard can’t express.
• Motor impairments: anyone using a switch device, head pointer, or other assistive input that doesn’t provide fine-grained pixel targeting faces the same lockout as a keyboard-only user.
• Screen reader users: hear only a generic “graphic, link” announcement with no indication of what regions exist or where activating the link will lead, since server-side maps carry no per-region text at all.

What users experience

Devon uses a keyboard exclusively after a repetitive strain injury made mouse use painful. He’s trying to find the accessibility services office on a university website’s visual campus map, built as a server-side image map. Tabbing to the map focuses one single link covering the entire image; pressing Enter sends a click at a fixed default coordinate, landing him on an unrelated department’s page every time, with no way to aim at the building he actually needs.

How do I fix it?

Replace the server-side image map entirely with a client-side image map, using a <map> element and <area> children that each carry a real href. This works because each <area> becomes its own independently focusable, keyboard-activatable link the moment it has an href, and the browser resolves which region was clicked (or, for keyboard users, which area currently has focus) without sending anything to the server first.

If the visual map isn’t essential to the task (for example, if users mainly need to reach a fixed list of destinations), replacing it with a plain set of text links is often the simpler, more reliable fix, since it sidesteps image-map markup and its coordinate math entirely.

Code Examples

<a href="/map-handler">
  <img src="/campus-map.png" ismap alt="Campus map">
</a>

<!-- Method 1: client-side image map - each area is its own keyboard-focusable link -->
<img src="/campus-map.png" usemap="#campus" alt="Campus map">
<map name="campus">
  <area shape="rect" coords="20,20,180,120" href="/buildings/library" alt="Library">
  <area shape="rect" coords="200,140,360,240" href="/buildings/accessibility-services" alt="Accessibility Services">
</map>

<!-- Method 2: plain links when the visual map isn't essential to the task -->
<nav aria-label="Campus buildings">
  <ul>
    <li><a href="/buildings/library">Library</a></li>
    <li><a href="/buildings/accessibility-services">Accessibility Services</a></li>
  </ul>
</nav>

The client-side map keeps the same visual image but gives every clickable region its own real href, so the browser, not the server, resolves navigation, and each area becomes a normal, Tab-reachable link with its own accessible name from its alt attribute. The plain-links version drops the coordinate-based image entirely in favor of ordinary navigation, which is simpler to build and maintain when the map graphic itself isn’t the point.

Common Mistakes

Mistake: “This is a 1990s pattern nobody actually uses anymore.” Server-side image maps are rare in new development, but they persist in legacy CMS templates, old government and university sites, and content migrated wholesale from earlier site versions without anyone reviewing the underlying markup. RedFlag flags this rule specifically because it still turns up in real audits of older or migrated sites, not because it’s common on modern builds.

Mistake: “Adding a usemap attribute alongside ismap covers both cases.” Combining both attributes doesn’t remove the server-side behavior: a browser encountering both still treats the element as a server-side map first in the relevant legacy code paths this pattern was designed for. The fix is to remove ismap and rely on usemap alone, not to layer one on top of the other.

Mistake: “A keydown handler on the img element can make this keyboard-accessible.” Attaching a keyboard event listener to an <img> doesn’t give it a tab stop, a visible focus indicator, or any of the semantics a real link provides automatically, and it still leaves the fundamental problem unsolved, since there’s no way to represent “which coordinate region” through discrete key presses without essentially rebuilding a client-side map by hand.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s server-side-image-map rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. The rule inspects every <img> element for the presence of an ismap attribute and flags it directly: the check is a simple attribute presence test, not an analysis of whether the image actually functions as navigation.

False negative: none typical for this specific check, since the presence of ismap is what the rule looks for and that attribute is either present or absent. The broader limitation is scope, not accuracy: RedFlag can’t detect a replacement client-side map that’s still missing alt text on its area elements. That’s a separate rule. False positive: none typical, since ismap has no legitimate accessible use case that would make its presence a false alarm. Manual step: confirm the image map is actually removed or replaced rather than just supplemented, and that every area in a client-side replacement has real, working alt text.

Manual Testing

1. Open the page in Chrome or Firefox using only the keyboard (no mouse).
2. Tab to the image map link and press Enter.
3. Confirm you land on a specific, expected destination rather than a default or unrelated page.
4. Repeat with NVDA or VoiceOver running and confirm the screen reader announces a specific destination name before activation, not just a generic “graphic, link.”
5. If Tab reaches only one link for the entire image with no way to choose a specific region, or if activating it sends you somewhere unpredictable, the check fails.

Related WCAG Success Criteria

2.1.1 Keyboard: All functionality must be operable through a keyboard interface. A server-side image map fails this criterion directly, since the coordinate-based interaction it depends on has no keyboard equivalent by design.

Related Issues

Image map area element is missing alt text covers the fix this page recommends: once a server-side map is replaced with a client-side one, its area elements need their own accessible names to be fully usable.

Interactive element is not reachable by keyboard shares the same underlying keyboard-operability principle, on any interactive element rather than specifically an image map.

Content is skipped in the keyboard focus order, Frame does not contain focusable content, and Scrollable region is not keyboard focusable cover other ways an element or region can be reachable visually but unreachable by keyboard, the same class of failure this rule represents for image maps specifically.

References

• W3C Understanding 2.1.1: Keyboard
• MDN: ismap attribute
• MDN: The Image Map element