The accessible store locator guide.

Why store locators fail accessibility, and why nobody notices until someone has to use one.

Most locator widgets ship as a search box, a map, and a list. That sounds simple, until you try to use it without a mouse. Locators concentrate four of the hardest accessibility patterns into one screen: a form, a dynamic list, a custom map control, and content that updates without a page reload. Each one is a place teams quietly cut corners.

The result is widgets that look fine in a screenshot but lock out anyone navigating with a keyboard, a screen reader, voice control, or a low-contrast display. The failures rarely surface in QA because most test plans use a mouse on a high-contrast monitor.

A gallery of common locator failures: what to do instead.

These four patterns show up in roughly four out of five locator widgets we audit. None of them are exotic. All four are repeatedly fixable in an afternoon if the build is set up to allow it.

Keyboard navigation: the eight checks every locator should pass.

If you can't complete a search and choose a location using only the Tab, Shift+Tab, Enter, Space, Escape, and arrow keys, the locator is not accessible. Full stop. This is the cheapest test you can run, and it surfaces most locator defects.

• Tab order is logical Search input, then filters, then results, then map controls. Avoid skipping around the visual layout.
• Every interactive element is reachable Pins, expand toggles, “Get directions” links. If you can click it, you can tab to it.
• Focus is always visible Never outline: none without an obvious replacement (2 px outline + offset is standard).
• Filters use the right keys Single-select chips behave like radios; multi-select chips behave like checkboxes; segmented groups respond to ←→.
• The map can be skipped Provide a “skip to results” link, or never let the map become a tab stop unless the user opts in.
• Modals close on Escape “Get directions,” “Hours of operation,” and any flyout returns focus to the trigger when dismissed.
• Hit targets are at least 24×24 CSS pixels (WCAG 2.2 SC 2.5.8). Pin clusters and chip rows are common offenders.
• No keyboard-only dead ends Every focused element has a way back. If autocomplete opens, Escape must close it without losing the input.

Screen-reader and semantic checklist.

A keyboard-navigable locator is not automatically a screen-reader-friendly locator. The next layer is what the page tells assistive tech: roles, names, structure, and announcements when state changes.

• Wrap the widget in a landmark Use <section aria-label="Find a location"> or <search> when supported.
• Use real heading hierarchy The locator’s heading is an <h2> on most pages; result group labels are <h3>.
• Results are a list Use semantic <ul><li>. A screen reader will say “list with 3 items.”
• Status messages are announced Announce “3 locations found” via aria-live="polite" when results change.
• Maps have an accessible name Use aria-label="Map showing 3 locations", with a textual list nearby that does the actual work.
• Inputs have associated labels Use <label for="zip"> matched to id="zip". Placeholders are not labels.
• Errors are tied to fields Connect the input to the error text via aria-describedby. “Invalid zip” by itself, somewhere on the page, is not enough.

Sample markup

<div class="locator">
  <input type="text"
         placeholder="Enter zip"/>
  <div class="results">
    <div>Mission Branch</div>
    <div>Bernal Heights</div>
  </div>
</div>

<section aria-labelledby="loc-h">
  <h2 id="loc-h">Find a location</h2>
  <label for="zip">Zip or city</label>
  <input id="zip" type="text"/>
  <p role="status">3 locations near 94110</p>
  <ul>
    <li>…</li>
  </ul>
</section>

Colour contrast and focus states.

Contrast is the failure most often caught by automated scanners. It's also the one most often re-introduced when a brand colour gets re-tinted late in the project. Pin down the contrast targets early so brand decisions don't corner the engineering team.

WCAG 2.2 AA contrast targets

Pass / fail in the brand palette

Sample combinations from the dropafinder palette, with the same brand swatches in different roles. The cyan accent passes against navy as a UI accent, but not against white as text.

Focus indicators: do and don’t

Map and list interaction concerns.

The single biggest design decision in an accessible locator is which surface is primary. Maps are a visual aid; the list is the source of truth. Build the list first, then enhance with a map.

WCAG 2.2 AA criteria, mapped to locator patterns.

These are the success criteria a locator audit comes back to most often. Use this as a punch list. Every row is something you can verify with a 5-minute manual check.