A map is one of the few interfaces where the accessible answer is usually not a better component. It is making sure the information the map carries also exists in a form that does not require seeing it. Get that right and most of the rest of this page becomes optional.
Give the Address in Text
Somebody on your contact page wants the address, the opening hours, and how to get there. A map shows all three to people who can see it. Text gives all three to everybody, including the person copying the address into their own navigation app, which is most people.
In W3C's own vocabulary a map is a complex image, and a complex image takes two parts. A short description that identifies it, and a longer one carrying the information the picture holds. On a contact page your address block is the long description, and it works better sitting on the page where everybody can read it than hidden behind an attribute. W3C makes that argument by naming who benefits from a visible description rather than a hidden one, which is people with low vision, people with learning disabilities, and anybody who is not already an expert in what they are looking at. So the text is the content, and the map is the enhancement.
The test
Turn the map off entirely. If the page still tells somebody where you are and how to reach you, it works. If it does not, the map is carrying information nothing else on the page carries, and everything below applies to you.
What an Embedded Map Owes You
An embedded map is somebody else's iframe sitting on your page, and the failures inside it are still findings against your page.
- Give the iframe a
titlethat says what it holds, such as Map of our Leeds office. Without one a screen reader user has to enter the frame to find out what it is, and what they hear before that depends on the screen reader. Some say frame, some read the source URL, some read the embedded document's own title. None of them tells the reader what it is for. - Check whether focus can get out. Not whether the widget captures arrow keys, which plenty of legitimate widgets do. The rule is that focus has to be able to leave, and that if leaving takes something other than Tab or the arrow keys, the user has to be told how. A map that swallows the arrows and releases Tab is fine. A map that releases only on Escape and never says so is not.
- Watch scroll-to-zoom. A map that eats the page scroll when the pointer passes over it is a real problem for anybody who cannot easily get past it. Whether it is a WCAG failure depends on the details, and it is worth fixing either way.
The keyboard trap rule is the one place where the third-party argument is not a matter of opinion. It belongs to a group of four criteria that apply to everything on the page whether or not that content is part of your conformance claim, on the reasoning that content nobody can escape from interferes with the whole page. So a trapped map widget cannot be scoped out of a claim, however it got there.
Everything else about a third-party embed is more arguable, and your client will find the argument, so it is worth knowing. The conformance rules let an author claim partial conformance for content genuinely outside their control, and widgets are one of the categories named. A site owner whose platform injects a map has a real case. A site owner who chose the provider, pasted in the embed and configured it has a much weaker one.
Taking the Map Out of the Tab Order Does Not Work
We used to tell readers that a decorative map beside a text address could simply be removed from the tab order, so nobody had to walk through an interactive canvas they could not use. That advice is off this page, because we went looking for a mechanism that does it and could not find one that holds up.
tabindex="-1" on the iframe does not reliably keep Tab out of the frame, because the document inside the frame has a tab order of its own. aria-hidden="true" on a wrapper is worse, because the controls inside stay focusable while disappearing from the accessibility tree, so a keyboard user lands on something their screen reader has nothing at all to say about. The inert attribute is the one candidate that should work on paper, and we have not tested it against an embedded frame, so we are not going to tell you that it does.
There is a second reason to leave the map alone, and it survives whatever the testing turns up. Hiding a working control from keyboard users while pointer users keep it is not a neutral tidy-up. It hands two different pages to two different people. Give the frame a title, confirm focus can leave it, put the address in text, and let the map be a map.
Interactive Maps That Do Carry Data
A store locator, a coverage map, a results-by-region view. Here the map genuinely holds information nothing else holds, and the answer is still a second view rather than a rebuilt map.
- Offer a list beside the map showing the same data. This is almost always less work than making a mapping library operable, and it is W3C's own advice for the static case, where it calls the pattern redundant text links.
- Keep the two in sync, so filtering one filters the other and neither can quietly go stale.
- Do not attach the list to the map with
aria-describedby. A description is announced as one continuous run of text with no headings and no table structure inside it, so a list of forty branches arrives as one very long sentence. Put the list on the page as a list. - Give interactive pins names and keyboard access, not just a click target. There is a specification for this that almost nobody uses. The ARIA graphics roles cover structured graphics where the layout carries meaning, and a map icon is the specification's own example of
graphics-symbol, withgraphics-documentfor the map itself andgraphics-objectfor a meaningful region inside it.
Pinch Is One Rule, Pan Is Another
These get treated as one problem and they are two, with different exceptions, so an audit finding that names the wrong one is a finding somebody can argue away.
Pinch to zoom is a multipoint gesture, which puts it under 2.5.1 Pointer Gestures. W3C's own worked example for that criterion is a map, and the answer it names is plus and minus buttons. The alternative you provide can be a tap, a click, a double tap, a long press, or a click and hold. What it cannot be is another gesture that depends on a path.
Drag to pan is a different shape. A drag is four actions, establishing a start point, pressing and holding, moving, and releasing, and the direction never matters to the interaction, which is exactly what separates it from a swipe. That puts it under 2.5.7 Dragging Movements, and W3C's first worked example there is also a map, answered with directional buttons.
One condition decides whether the second finding stands. The dragging rule does not reach scrolling the browser is doing for you, including a section made scrollable with CSS overflow. A mapping library that suppresses native scrolling and implements its own panning is squarely in scope. A large map image inside a scrolling container is not. And panning is not essential in the sense the exception means, because directional buttons do the same job and conform.
The Rule That Runs in Your Favor
Clients ask why the map will not collapse into a single column on a phone, and the answer is that it does not have to. The reflow rule excepts content that needs a two-dimensional layout, and its list of examples opens with maps. Two-dimensional scrolling is acceptable for the part of the page that genuinely needs it. That is a rare thing on an audit, a rule that gives you something back, and it is worth saying out loud in the report.
Color on a Map, and the One Exception
Map layers lean on color harder than most interfaces. Coverage areas, density, routes, availability. Take the color away and the reader has to be able to tell them apart some other way, which means patterns, labels, and shapes. The quick check is a greyscale screenshot, and it works for a reason worth knowing. Two colors that differ in lightness by 3:1 or more count as a second visual distinction in their own right, and greyscale is what lightness looks like on its own. So a map that survives greyscale has already taken the escape the color rule offers.
One map type has a documented exception, and it is the type where the advice above cannot work. Where a color gradient represents a measurement, which is what a heat map or a choropleth is, the non-text contrast rule treats that presentation as essential, so the 3:1 requirement on the graphical objects does not apply. The color rule still does, and the answer there is labels and values rather than hatching. The same criterion also steps back where a graphic carries text conveying the same information, so a map with its regions labeled has taken that escape too.
The Other Thing Called an Image Map
There is a naming collision worth knowing before you go looking for guidance. In W3C's vocabulary an image map is not a geographic map. It is a static image with clickable hotspots defined by map and area elements, and a clickable regional coverage graphic or a floor plan is exactly that. It needs text alternatives in two places, on the image itself to say what the whole thing is, and on every single area to say where that hotspot goes or what it does. Use each image map once on a page, put the map element next to its image, and offer the same links as ordinary text somewhere as well. Our fix guide covers naming the hotspots.