Image map area element is missing alt text

What is this issue?

An <area> element (a shape-defined clickable region inside a <map>, associated with an <img> through the usemap attribute) has no alt attribute. Each area behaves as its own link, complete with an href pointing somewhere specific, but with no text describing that destination.

This is distinct from the <img> element the map is attached to. The image itself needs its own alt describing what the overall picture shows; each area inside the map needs a separate alt describing that specific clickable region’s destination: two different accessible names doing two different jobs on the same image map.

Why does this matter?

Every area without alt text is a link with no accessible name, and a link with no name gives a screen reader user nothing to decide whether to activate it. On a genuinely non-rectangular clickable image, such as an interactive floor plan, a seating chart, or a map with irregularly-shaped countries, the visual shape itself carries the meaning a sighted user relies on to know what they’re about to click. That meaning is completely lost without text standing in for it.

A seating chart image map with unlabelled area elements for each section announces every clickable region as just “link” to a screen reader user, over and over, with no way to tell “Section A” from “Section B” without guessing. A sighted user glancing at the same chart instantly sees which section is which from position and shape alone.

Who is affected?

• Screen reader users: hear a generic, unlabelled “link” announcement for every hotspot on the image map, with no way to distinguish one clickable region from another before activating it.

What users experience

Owen uses VoiceOver on his Mac to buy concert tickets through a seating-chart image map. He tabs through the map and VoiceOver announces “link” for each section, with no section name, price tier, or location: every hotspot sounds identical. He has no way to select the section he actually wants without clicking through each one, checking the resulting page, and going back if it’s wrong, turning a task that should take seconds into repeated trial and error.

How do I fix it?

Add alt text to every area element describing where that specific region leads, in the same style you’d write link text for an ordinary <a>: name the destination, not the shape. This works because alt is the accessible-name source for area elements the same way it is for img, and a screen reader announces it exactly like link text once the region receives focus.

Write each area’s alt as if it were standalone link text, since that’s functionally what it is: “Northern region,” not “clickable shape in the top-left of the map.”

Code Examples

<img src="/seating-chart.png" usemap="#chart" alt="Venue seating chart">
<map name="chart">
  <area shape="rect" coords="0,0,150,100" href="/seats/section-a">
  <area shape="rect" coords="160,0,310,100" href="/seats/section-b">
</map>

<img src="/seating-chart.png" usemap="#chart" alt="Venue seating chart">
<map name="chart">
  <area shape="rect" coords="0,0,150,100" href="/seats/section-a" alt="Section A, floor level">
  <area shape="rect" coords="160,0,310,100" href="/seats/section-b" alt="Section B, floor level">
</map>

Each area’s alt now states exactly where that hotspot leads, so a screen reader user tabbing through the seating chart hears “Section A, floor level, link” and “Section B, floor level, link” instead of two indistinguishable “link” announcements, the same information a sighted user gets from the chart’s visible labels.

Common Mistakes

Mistake: “The img element’s alt already describes the whole map, so the areas don’t need their own.” The image’s alt describes the picture as a whole (“Venue seating chart”); it says nothing about where any individual clickable region leads. Each area is a separate link with its own destination and needs its own alt; the image-level description and the region-level descriptions answer different questions.

Mistake: “Alt text on an area should describe the region’s shape or position.” Since each area functions as a link, its alt should describe the destination, exactly like ordinary link text: “Section A,” not “rectangular region in the upper-left.” Describing shape or position tells a screen reader user nothing about what clicking there actually does.

Mistake: “This pattern is obsolete, so it’s not worth fixing properly.” Client-side image maps are less common than they once were, but they’re still the most practical way to make a genuinely non-rectangular clickable image accessible, such as a diagram, a chart, or a geographic map, and when they’re used at all, unlabelled area elements are a common, easily-missed failure precisely because the pattern is unfamiliar to developers who rarely touch it.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. This page’s ruleId, redflag-area-alt, is a docs-only alias: src/lib/wcagData.js’s DOCS_URL_MAP redirects the underlying axe-core rule area-alt to this redflag-prefixed docs slug so the extension’s “View docs” link resolves correctly. The detection logic itself is unmodified, stock axe-core; RedFlag adds no custom logic on top. axe-core calls the check as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set, and inspects every <area> element inside a <map> for a non-empty accessible name via alt, aria-label, or aria-labelledby.

False negative: axe-core confirms alt text exists; it cannot judge whether it accurately describes the destination. An area alt="Link" on a seating-chart section passes the check while telling the user nothing about where it goes. False positive: none typical for this check, since resolving to a non-empty accessible name is a binary condition axe-core evaluates reliably. Manual step: confirm each area’s alt text accurately names its actual destination, not a generic placeholder.

Manual Testing

1. Open the page in Chrome or Firefox with NVDA or VoiceOver running.
2. Tab through each clickable region of the image map.
3. Listen to what’s announced for each area: it should be a specific destination name, not just “link” with no further text.
4. If any region announces only “link” with no accompanying text, the check fails.

Related WCAG Success Criteria

1.1.1 Non-text Content: All non-text content must have a text alternative that serves the equivalent purpose. An area with no alt is a direct failure, since it’s a clickable region with no text alternative to represent it.

4.1.2 Name, Role, Value: Every interface component must expose a name, role, and value. An unlabelled area has a role (link, from its href) but no name, failing 4.1.2 on the name requirement specifically.

Related Issues

Image is missing alt text is the equivalent missing-text-alternative failure on a plain <img> rather than a clickable image-map region.

Image input is missing alt text and Object element has no text alternative cover the same naming failure on two other non-text element types axe-core checks separately.

Alt text is a filename or placeholder is the next failure mode past this one: alt text that exists on an image or area but is generic junk instead of a real description.

Server-side image map is used covers the more serious sibling failure: a coordinate-based image map with no keyboard access at all, which client-side maps like this one exist specifically to replace.

References

• W3C Understanding 1.1.1: Non-text Content
• MDN: area element
• WebAIM: Alternative Text