Area Needs Alt

Element Code: IM-002

What an area element is

An image map lets you carve one image into multiple clickable regions. It uses a <map> with child <area> elements, each defining a shape (rect, circle, poly) and a link. Classic example: a floor plan or a diagram where different parts click through to different pages.

<img src="office.png" usemap="#plan" alt="Office floor plan">
<map name="plan">
  <area shape="rect" coords="0,0,120,90" href="/reception" alt="Reception desk">
  <area shape="circle" coords="200,80,40" href="/lab" alt="Research lab">
</map>

Here is the part people miss: each <area> is functionally a link, and the HTML spec requires an alt attribute on any area that has an href. The image's own alt describes the picture. The area's alt describes that specific clickable destination. They are not the same thing, and one does not cover for the other.

Why the missing alt matters

Screen readers announce the alt as the link name. When someone tabs to an area hotspot, assistive tech reads its alt text as the accessible name of that link. No alt, and the user hears something useless like the file name or "link" with no context. They are staring at an unlabeled door.

It is a WCAG failure. Missing alt on a linked area fails Success Criterion 1.1.1 Non-text Content. Automated checkers like axe, WAVE, and Lighthouse all flag it, and it is a common item on legal accessibility complaints.

Links without discernible text are weak SEO too. A link whose only content is an unlabeled image hotspot gives search engines no anchor context. The area alt is the anchor text equivalent for image map links, so leaving it blank throws away a real signal.

Empty is not always wrong, though. If an area is purely decorative or overlaps another that already carries the link, an intentionally empty alt="" is the correct way to hide it from assistive tech. The failure is a missing alt on a functional link, not a deliberately empty one.

How a screen reader sees it

How to detect it

The automated tools catch the missing attribute instantly. But I always tab through a real image map with VoiceOver at least once, because "has an alt" and "has a useful alt" are different tests, and only your ears catch the second one.

How to fix it, step by step

1. List every area with an href. Those are your functional links and every one needs alt text.

2. Write destination-focused alt. Describe where the link goes, not what the pixels look like. "Reception desk" or "View pricing", not "orange rectangle top left".

3. Keep it short. These behave like anchor text. A few words is plenty. Skip "link to" and "image of", the screen reader already announces it as a link.

4. Handle decorative overlaps deliberately. If an area is redundant or purely decorative, give it alt="" on purpose so assistive tech skips it cleanly. That is a decision, not an omission.

5. Consider whether you even need an image map. Honestly, image maps are fragile: they do not reflow on mobile and the coordinates break on resize. A block of real links or an SVG with proper labels is usually a better answer. If you can replace the map, that solves this at the root.

6. Re-run the audit. Confirm axe or Lighthouse shows zero area alt errors, then verify by ear.

DO vs DON'T

What good looks like

Every clickable area carries a short alt that names its destination, decorative areas are intentionally empty, and the image itself has its own descriptive alt. A user tabbing through with NVDA hears a clean list of named links, axe and Lighthouse report zero area alt issues, and search engines get real anchor context from each hotspot. Better still, on pages where the image map added nothing but fragility, you replaced it with plain labeled links and the whole problem disappeared.

FAQ