Making Store Locator Maps and Location Widgets Accessible for E-Commerce
Quick answer: A “Find a Store” or “Our Locations” map is non-text content, and
WCAG SC 1.1.1 Non-text Content
(Level A) requires a text alternative that serves the same purpose — a requirement WCAG’s own
Understanding doc illustrates with an interactive floor-plan image map, not a generic photo. On
top of that, the pins/markers on a modern JS-powered map are usually custom graphical elements
that need their own keyboard support and accessible names (SC 2.1.1 Keyboard, SC 4.1.2 Name,
Role, Value), and a plain embedded map iframe needs a descriptive title attribute so a screen
reader user knows what it is before deciding whether to enter it. Most store-locator
implementations get at least one of these wrong, and the most commonly used map API in the
industry — Google Maps — documents, in its own words, that markers are not keyboard- or
screen-reader-operable out of the box.
This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.1 AA requires for store-locator and map components and how to meet it, not whether a specific implementation carries legal risk.
The map is content, not decoration
It’s tempting to treat a store locator’s map as a visual nicety sitting next to the “real” content — a text list of addresses. But WCAG doesn’t carve out an exception for interactive graphics just because there’s also a fallback list somewhere on the page; the map itself is non-text content that needs an equivalent. The Understanding doc for SC 1.1.1 names an “image map” as one of its own worked examples: “An image of a building floor plan is interactive, allowing the user to select a particular room and navigate to a page containing information about that room. The short text alternative describes the image and its interactive purpose: ‘Building floor plan. Select a room for more information.’”
A store locator is the same pattern with pins instead of rooms. The fix isn’t a long alt
attribute crammed onto a <canvas> or <iframe> — it’s a genuine text alternative that serves
the same purpose: a parallel, programmatically readable list of the locations the map shows
(name, address, phone, hours, a “get directions” link), present in the DOM alongside the map, not
buried behind a separate “list view” toggle that itself requires operating the inaccessible map
to discover.
Custom map markers usually aren’t keyboard-operable by default
The visual map graphic is only half the problem. The pins marking each location are typically custom-rendered controls, and how they behave for keyboard and screen-reader users depends entirely on how the underlying map library was configured — it is not automatic.
Google Maps’ JavaScript API is the clearest, most checkable example, because Google documents
this behavior itself. For the legacy google.maps.Marker class, Google’s own
markers guide explains
that when many markers are on a page, the API optimizes performance by “rendering many markers as
a single static element,” and that you should “disable optimized rendering… when each marker
must be rendered as a separate DOM element.” The same page’s “Make a marker accessible” section
is direct about what that means in practice: “You can make a marker accessible by adding a click
listener event, and setting optimized to false. The click listener causes the marker to have
button semantics, which can be accessed using keyboard navigation, screen readers, and so on.”
Read the other direction, that’s an admission that the default, unconfigured behavior doesn’t
give markers button semantics at all — flattened into a single static graphic, a screen reader
has nothing to land on.
The current, non-legacy Advanced Markers API works differently under the hood but lands on the
same requirement. Google’s own accessible-markers
guide
states that “clickable markers respond to keyboard and mouse input, allowing users to navigate and
interact with them using the tab, arrow, and enter keys” — but only once a developer explicitly
sets the gmpClickable property to true and supplies a title string for the screen-reader
label. Neither is the default. The same page also notes that default marker size “meet[s] the
WCAG AA minimum size standard” for target size, which is a useful baseline but doesn’t say
anything about whether the marker can receive keyboard focus in the first place — see
our target-size article for that criterion
on its own.
The practical takeaway isn’t specific to Google Maps — it generalizes to most JS map libraries that render markers onto a canvas or as absolutely-positioned graphical layers for performance: assume markers are not keyboard-reachable until you’ve explicitly verified it, the same way you’d check any other custom-built control.
Bare iframe embeds need a real title
The simplest and most common store-locator pattern for a small e-commerce site isn’t a custom JS
map at all — it’s a single embedded Google Maps iframe pointed at one address on a Contact or
Locations page. That pattern has its own, older WCAG technique:
H64, “Using the title attribute of the frame element”,
whose stated objective is “to demonstrate the use of the title attribute of the iframe
element to describe its contents,” so that “users can determine which frame to enter and explore
in detail.” An iframe with no title (or a generic one auto-generated by an embed-code
snippet) forces a screen-reader user to enter the frame just to find out what it is, rather than
deciding up front whether it’s worth exploring — a small fix (title="Map showing our Denver store location") that most copy-pasted embed codes simply don’t include by default.
What if the site still uses a classic HTML image map?
Fewer sites do this today, but it still shows up on older storefront templates: a single static
image of a map with clickable <area> regions defined in HTML rather than a JS widget. WCAG has a
dedicated technique for exactly this case —
H24, “Providing text alternatives for the
area elements of image maps.” Its own description states the objective plainly: “to provide
text alternatives that serve the same purpose as the selectable regions of an image map… The
alt attribute of each area element serves the same purpose as the selectable area of the
image.” In practice, that means every <area> needs its own descriptive alt text (“Downtown
Seattle location — 123 Main St”), not a single alt on the parent <img> or, worse, nothing at
all.
Can an automated scanner catch this?
Only a narrow slice of it. A direct check of axe-core’s own rule
descriptions
turns up exactly two rules touching this territory at all — area-alt and
server-side-image-map — and both are scoped specifically to classic HTML <area>/<map>
markup, the pattern covered above that’s now the least common way to build a store locator.
There is no rule anywhere in the file for a JS-rendered map widget, whether it’s built on Google
Maps, Mapbox, Leaflet, or a custom canvas layer. That’s not a coverage gap in one weak rule — it’s
a structural blind spot, the same one covered in what automated scanners actually
miss: whether a marker was configured
to be clickable and keyboard-operable is a runtime JavaScript property, not something visible in
a static DOM snapshot. A scanner can confirm an iframe has a title attribute, but it can’t
tell you whether tabbing through a map actually reaches every pin, or whether pressing Enter on a
focused pin does anything at all. That takes a person operating the widget with a keyboard.
FAQ
Does a text list of locations next to the map count as the required text alternative? Yes, as long as it’s genuinely present in the page (not hidden behind a control that itself requires using the map) and covers the same information the map conveys — which location, and enough detail to act on it (address, hours, a way to get directions). It doesn’t need to be a literal transcription of the map’s visual layout.
Is it enough to just add alt text to a map screenshot image?
Not for an interactive map — alt text describes a static image, but a store locator’s map is
usually an interactive control with multiple selectable points, closer to the “image map” example
above than to a plain photo. A single alt string can name the map but can’t convey each location
individually the way a paired list or accessible markers can.
Do I need to rebuild my whole map widget to fix this? Not necessarily. For a JS map API like Google Maps, the fix is often a configuration change — enabling click handling and supplying title text for existing markers — rather than replacing the widget. The bigger structural fix, a parallel accessible list of locations, can usually be added alongside an existing map without touching the map code at all.
Get your store locator checked by a person, not just a parser
Quietramp’s $890 audits include a manual pass through interactive widgets like store locators and
embedded maps — actually tabbing through markers and checking what a screen reader announces, not
just confirming an alt attribute exists somewhere in the markup. See a real sample
report or check pricing — $99/month for ongoing re-checks
after fixes ship.
This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA does not resolve ADA or any other legal compliance question, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.
This article was drafted with AI assistance and reviewed by a person for accuracy before publication.