Accessible Store Locators and Maps
Store locators mix search boxes, map pins, and result lists that often fail keyboard and screen reader users. How to make finding a store usable for everyone.
A store locator looks simple: type a postcode, see nearby stores, pick one. Underneath sits an interactive map, a results list that updates silently, distance figures, and opening hours, each a place where assistive technology users get stranded.
The map gets the design attention and the list does the real work. This guide covers building a locator where the list is the primary route, the map is an enhancement, and every result can be read, reached, and acted on without a pointer.
Make the results list the main route
Every store the map shows should also appear as structured text: name, address, distance, hours, and a link to directions or the store page. A screen reader user who never touches the map should lose nothing except the picture.
Results must update in a way that is announced. When a search returns five stores, that count and the list itself should be reachable and readable, not swapped silently under a map the shopper cannot use.
Label the search and its filters properly
The location field needs a real label that says what to type, a city, postcode, or address, and an example helps everyone. Filters for services or accessibility features need labelled checkboxes, not clickable chips with no state announced.
Errors matter here: a location that is not found should produce a text message explaining what happened and suggesting a broader search, placed where screen readers will find it, not a silent shake or a red outline alone.
Do not hide store details inside pins
Map pins that reveal address and hours only on hover or tap hide core information from keyboard users. Pins should be focusable where the platform allows, and in any case the identical details must live in the list beside the map.
Phone numbers should be real links, accessibility information about the store itself, step free entry, hearing loops, parking, should be text in the result, because for many shoppers that detail decides which store they can visit at all.
Test the locator like a journey
Search by keyboard only, apply a filter, read the results with a screen reader, and follow a result through to directions. Then repeat on a phone with the screen reader running, where small tap targets and map gestures cause a second set of failures.
Retest after any locator plugin or map provider update. Third party locator widgets change their markup without notice, and the store page inherits whatever the update did to labels and focus order.
Related reading
If this topic is useful, these earlier guides go deeper on connected questions: Making Size Charts and Fit Guides Accessible, Accessible Loyalty Program Pages and Points Displays, and Colour Contrast for Sale Badges and Promo Labels.
Frequently asked questions
Why is the results list more important than the map?
Because the list can carry every fact the map shows, in text that assistive technology can read. A locator where the list is complete works for everyone. One where details live only in map pins excludes keyboard and screen reader users.
What should a locator search field label say?
What to enter and in what form, for example a town, city, or postcode, with an example if formats vary. A label that only says search leaves screen reader users guessing what the field expects.
How should no results be handled?
With a clear text message that no stores matched, plus a next step: widen the distance, check the spelling, or browse the full store list. Silence or a blank map reads as a broken page.
Should store accessibility features be listed in results?
Yes, in text. Step free access, parking, and hearing support decide whether a visit is possible for many shoppers, and that information belongs with the address and hours, not buried on a separate page.