Why Image Map Areas Must Have Text Alternatives

Image maps allow different regions of a single image to act as separate links. Each of those clickable regions must have its own text alternative that describes its purpose.

If an <area> element does not provide alternate text, screen reader users cannot identify what the link represents or where it leads. To assistive technologies, the hotspot exists visually but has no usable name.

Key Concepts (Quick Primer)

Image map
A single <img> element associated with a <map> element that defines multiple clickable regions using <area> elements.

Active <area> element
An <area> element with an href attribute. Only active areas function as links and are subject to this requirement.

Accessible name
The text a screen reader announces to identify an interactive element such as a link or button.
For <area> elements, the accessible name comes from alt, aria-label, or aria-labelledby.

WCAG Success Criteria

1.1.1 Non-text Content (Level A)
2.4.4 Link Purpose (In Context) (Level A)
4.1.2 Name, Role, Value (Level A)

Each active <area> element must expose an accessible name that describes the purpose or destination of that hotspot.

Why This Matters

Screen readers cannot interpret images visually. They rely entirely on text alternatives to announce and navigate interactive content.

For image maps, this means:

• Each clickable region must be announced as a distinct link
• Users must be able to understand what each link does before activating it

When alternate text is missing, screen readers may announce the hotspot as:

• “link”
• the raw URL
• nothing meaningful at all

This forces users to guess and makes navigation slow, error-prone, and frustrating, especially when multiple hotspots exist within a single image.

Who This Helps

This requirement primarily supports:

• Screen reader users navigating via link lists
• Keyboard-only users tabbing through hotspots
• Users with low vision who rely on text alternatives
• Users who explore pages non-visually and out of linear order

How Screen Readers Actually Announce <area> Elements

Screen readers treat each <area> as an individual link.

Typical behaviour:

• NVDA / JAWS:
  Each <area> appears as a separate entry in the Links List.
• VoiceOver:
  Hotspots are available through the Rotor under Links.

If an <area> has no alternate text, the link may be announced simply as “link” or by its URL, giving no indication of what part of the image it represents.

Duplicate or generic labels such as “More” or “Click here” are technically present but make link lists unusable in practice.

What “Alternate Text” Means for <area>

Each active <area> must provide an accessible name.

Preferred approach
Use the native alt attribute.

Fallback approaches
Use aria-label or aria-labelledby only when alt cannot be used. The text must describe the specific purpose of that hotspot, not the image as a whole. The <img> element itself must also have its own alt text describing the overall image.

Passing Example

<img src="images/solar_system.jpg"
     alt="Solar system diagram"
     usemap="#planets">

<map name="planets">
  <area shape="rect"
        coords="115,158,276,192"
        href="https://en.wikipedia.org/wiki/Mercury_(planet)"
        alt="Mercury">

  <area shape="rect"
        coords="115,193,276,234"
        href="https://en.wikipedia.org/wiki/Venus"
        alt="Venus">
</map>

Why this passes:

• The image has descriptive alternate text
• Each hotspot has a unique, meaningful label
• Screen readers announce each <area> as a clear, distinct link

Common Failure Patterns

This requirement fails when:

• <area> elements are missing alt text
• All hotspots share identical labels
• Only the <img> has alternate text
• ARIA labels are used unnecessarily instead of alt
• Server-side image maps are used
• Mouse-only interactions are required

Server-Side Image Maps (Do Not Use)

Server-side image maps rely on mouse click coordinates and are inaccessible.

Failing example:

<a href="/maps/nav.map">
  <img src="/images/navbar.gif" ismap>
</a>

Problems:

• Not keyboard accessible
• No text alternatives per hotspot
• Screen readers cannot determine link purpose

Server-side image maps should never be used.

Relationship to Links and Focus Order

Each active <area> behaves like a link.

That means:

• It must be focusable
• It must have an accessible name
• It appears in sequential focus order based on DOM order

Poor ordering or duplicate labels can make keyboard navigation and screen reader link lists confusing, even if alternate text is technically present.

Rule Description

Every active <area> element in an image map must provide alternate text that describes the purpose of the link. The image itself must also have appropriate alternate text.

The Algorithm

1. Identify images using usemap
2. Locate the associated <map> and <area> elements
3. For each active :
   • Check for alt, aria-label, or aria-labelledby
4. Verify the text describes the hotspot’s purpose
5. If any active lacks meaningful text:
   • The criterion fails

How to Avoid This Issue

• Avoid image maps when standard HTML links will work
• If image maps are necessary:
  • Use alt on every active <area>
  • Ensure labels are unique and descriptive
• Avoid server-side image maps
• Test with both keyboard and screen reader navigation
• Review link lists, not just visual behaviour

How to Test This

• Navigate the page using a screen reader’s links list
• Confirm each hotspot is announced clearly and uniquely
• Navigate the image map using the keyboard
• Inspect markup to ensure no active <area> is missing alternate text

Wrapping Up

Image maps compress multiple links into a single visual element, but accessibility requires each link to remain distinct and understandable. Every active <area> represents a real navigation choice. Without alternate text, that choice becomes invisible to assistive technologies. Providing clear, descriptive text for each hotspot ensures that image maps remain usable, navigable, and understandable for all users.