Accessible Store Locators and Pickup Selection: Maps Are Not the Only Way In

A store locator built around an interactive map excludes anyone who cannot use the map. A text list with distances, a postcode search that tolerates errors, and pickup selection that works by keyboard fix most of it.

Find your nearest store sounds simple until the locator loads. A map fills the screen, pins cluster on top of each other, and the actual list of stores, with addresses and opening hours, only appears when a pin is clicked. A keyboard user tabs into the map and may not get out again cleanly. A screen reader user gets a region labelled map and a search box whose results are announced nowhere. The information they came for, which store, where, and when it is open, is on the page in a form they cannot use.

A locator has two jobs and only one of them needs a map. Showing where stores are relative to each other is a visual job. Telling a customer the nearest store, its address, its hours, its phone number, and whether it has stock or offers pickup is a text job, and text is what assistive technology, search engines, and slow connections all handle best. Build the text version as the real locator and the map as an enhancement, and most locator defects disappear.

The list is the locator

Present results as a list in distance order, each entry a heading with the store name, followed by address, distance, hours for today, phone number as a tappable link, and links for directions and for selecting this store for pickup. Update that list when the search changes and announce the update with a polite live region: three stores found near your postcode. Without that announcement, a screen reader user submits the search and hears nothing, which reads as a broken page.

Distance needs a basis. If it is straight line distance, say so, or a customer will be sent to a store across a river with no nearby crossing. Sort order should also be controllable, and the selected store in a pickup flow must be exposed as selected in the same way a variant selector is, not just highlighted in a brand colour. WCAG 1.4.1 Use of Color applies to pickup selection exactly as it does to size swatches.

Search that tolerates real postcodes

People mistype postcodes, paste them with spaces, use a work postcode for a home delivery area, or search by town because they do not know a postcode outdoors. Handle spaces and case, offer the nearest matches when there is no exact result, and never return a bare no results with no next step. State the search radius and let the user widen it. An error message that names the problem, we could not find that postcode, check it or search by town instead, meets 3.3.1 and 3.3.3. A red border on the field meets neither.

Autocomplete suggestion lists are their own accessibility task. Suggestions need keyboard operation with arrow keys, Escape to dismiss, and the chosen value placed into the field, following the combobox pattern rather than a homemade list that only a mouse can use. Test it with the keyboard alone, including the case where there is exactly one suggestion and the case where there are none.

Map behaviour and the way out

If you keep the map, give it a title or label that says what it is, make sure it does not trap keyboard focus, and do not make pins the only route to a store's details. Third party map embeds vary widely in keyboard support and you cannot fix their internals, which is another reason the list must be complete without them. A skip past the map link or a list placed before the map in reading order are both reasonable patterns.

Pickup selection at checkout deserves a separate test, because it often reuses the locator in a compressed form with its own faults: a change store link that opens a modal, radio options announced without distances, and a confirmation that never states which store was chosen. Read the checkout summary back. If the chosen store's name and address do not appear in text in the order summary and confirmation email, a customer has no accessible record of where their order is going.

Related reading: ADA Risk in Age Gates and Date of Birth Fields, Testing Contrast in Disabled Buttons, Sold Out Options, and Placeholder States, ADA Risk in Embedded Size Charts, Fit Guides, and Care PDFs.

Frequently asked questions

Does an interactive map have to be fully accessible?

The information it conveys does. A map itself is hard to make equivalent, so provide the same information in text: the list of stores, addresses, distances, and hours. That text alternative is what makes the service accessible, and it also serves users on slow connections or with maps blocked.

What should a locator announce after a search?

The number of results and the area searched, through a live region, followed by a results list that a user can navigate to. Silence after submitting a search is the most common locator failure for screen reader users, and it is fixed by announcing the result count and moving or offering focus predictably.

How should distance be shown for pickup stores?

As text with each store, with the basis stated if it is straight line distance, in a consistent unit for the market. Distance should also be part of the accessible name or description of the option when selecting a store, not only a visual badge on a map pin.

Can I rely on a third party locator widget?

You can use one, but you ship its accessibility. Test the widget for keyboard traps, unlabelled controls, and results that never reach a list. If the vendor cannot provide a text results view, build your own list alongside it from the same store data.