A store locator is the shortest route between a website and a shop floor. That is why nobody notices when the route is cut: the map loads, the pins sit where they should, the zoom buttons answer a mouse click. Anyone who does not use a mouse faces a grey rectangle with no way out. Map widgets are a reliable place to find barriers in an audit: a graphic without a text alternative, undersized controls, dragging gestures with no substitute, labels over aerial imagery without contrast. This article shows how to build a location search that works without a mouse, without colour perception and with a screen reader. The map stays what it is and gains an equivalent list beside it — the pattern that accessible web development prescribes for two-dimensional content.
Key takeaways
- In standards terms a map is an image, and what is required is a text alternative serving the same purpose (W3C, WCAG 2.2, SC 1.1.1) — the branch list, not an alt attribute on a map tile.
- Map controls need at least 24 by 24 CSS pixels (W3C, WCAG 2.2, SC 2.5.8). Zoom buttons and pins fall short because they arrive with the framework and are rarely measured.
- Dragging the map needs a single-pointer alternative (W3C, WCAG 2.2, SC 2.5.7). Four directional buttons satisfy this and appear in the standard's own explanatory text.
- 67 per cent of websites remove the default focus outline (Web Almanac, 2025), which costs keyboard users every sense of position.
- Only 20 of 65 shopping sites tested could be operated by keyboard alone (Aktion Mensch, 2025) — a test store locators regularly fail.
- Providing a service without accessibility can carry a fine of up to one hundred thousand euros under the German Accessibility Strengthening Act (BFSG).
Why the map alone does not do the job
From the standard's point of view a map is an image, and WCAG asks for a text alternative serving the same purpose (W3C, WCAG 2.2, SC 1.1.1). In a location search that purpose is not to show the geography of a region but to find the nearest branch, read its address, check its hours and set off. The equivalent is a structured list carrying the same data and offering the same actions. How far an alt text reaches is covered in our piece on accessible images and alt text.
That the map surface may stay two-dimensional is written into the standard: images required for meaning are named alongside video, games, presentations and data tables as an exception to the reflow requirement (W3C, WCAG 2.2, SC 1.4.10). Projects routinely stretch that exception. It covers the map surface, not the control bar beside it, not the result list, not the search field and not the filters.
The gap between intention and practice is measured. On 95.9 per cent of home pages surveyed, automatically detectable WCAG failures were present (WebAIM Million, 2026), averaging 56.1 errors per page (WebAIM Million, 2026). Pages are also growing faster than review routines keep up: 1,437 elements on average is an increase of 22.5 per cent within a year (WebAIM Million, 2026).
The list is not a consolation prize
What the legal framework asks of a location search
The German Accessibility Strengthening Act defines accessibility in three words that read well as an audit question: products and services are accessible when people with disabilities can find, access and use them in the usual manner, without particular difficulty and without outside help (BFSG). A store locator that runs on mouse input alone fails all three, regardless of whether the module was built in-house or embedded.
Scope is set by the act itself, not by the regulation: Section 1 (3) BFSG lists the covered services exhaustively — telecommunications services, certain elements of passenger transport services, consumer banking services, e-books and services in electronic commerce (BFSG). Where the service behind the store locator falls under that list, for instance as a service in electronic commerce, the requirements of Section 12 BFSGV apply, which expressly names websites, including the associated online applications and services offered on mobile devices (BFSGV). A store locator is precisely that, and its main use case is mobile. Only in that case does the act's fine of up to one hundred thousand euros come into play (BFSG); on a purely informational site without electronic commerce the connecting factor is missing to begin with. Which thresholds market surveillance applies and which records it asks for is set out in the BFSG requirements.
SC 1.1.1 Non-text Content
The map needs an alternative serving the same purpose: the branch list with address, distance and opening hours (W3C, WCAG 2.2, SC 1.1.1).
SC 2.1.1 Keyboard
Every function must be operable through the keyboard interface, from search field to radius filter to marker (W3C, WCAG 2.2, SC 2.1.1).
SC 2.4.7 Focus Visible
The focus ring has to travel visibly through map and list; a suppressed outline is a failure here (W3C, WCAG 2.2, SC 2.4.7).
SC 2.4.11 Focus Not Obscured
Sticky map bars, consent layers and chat bubbles must not entirely hide the focused list entry (W3C, WCAG 2.2, SC 2.4.11).
SC 2.5.7 Dragging Movements
Panning the map by dragging needs a single-pointer alternative, such as four directional buttons (W3C, WCAG 2.2, SC 2.5.7).
SC 2.5.8 Target Size
Zoom buttons, pins and list rows keep at least 24 by 24 CSS pixels unless an exception applies (W3C, WCAG 2.2, SC 2.5.8).
How often that catalogue is missed was shown by a survey taken shortly before the act took effect. Of 65 shopping sites drawn from the 500 most visited company websites in Germany, only 20 of 65 could be operated by keyboard alone (Aktion Mensch, 2025). Overall only one third of the shops passed the accessibility test (Aktion Mensch, 2025). Store locators and filter bars are the usual points of failure: adopted ready-made, rarely checked afterwards. Anyone responsible for embedded modules will find the liability question sorted out in our article on third-party widgets and BFSG duties.
The result list is the real text alternative
The most durable pattern is a split view: map surface on the left, result list on the right, both fed from the same data set. The list is the primary control for everyone who cannot depend on the visual map. Technically it is an ordinary list: a heading with the branch name, then address, distance, opening hours, a note on how accessible the site is, a link to the detail page and one for route planning. This structure holds even when the map fails to load.
That screen reading happens mostly on mobile devices matters for the pattern. In the most recent large user survey, with 1,539 valid responses (WebAIM, Screen Reader Survey 10), 93.6 per cent of respondents with disabilities reported using a mobile screen reader (WebAIM, Screen Reader Survey 10). What that means for announcements, roles and states is developed in our piece on screen reader optimisation.
| Aspect | Map as the only control | Map plus equivalent result list |
|---|---|---|
| Keyboard operation | markers stay unreachable | every location is a list item with a link |
| Screen reader | reads out an empty graphic | reads name, address, distance and hours |
| No map or no consent | empty area, no way forward | the full location list stays usable |
| Zoom at 400 per cent | the control bar breaks too | list reflows, map stays two-dimensional |
| Search with no results | map keeps showing some extent | status message names count and radius |
| Maintenance effort | map data and address data drift apart | one source feeds both views |
| Auditability | findings sit in a third-party frame | findings sit in your own markup |
Alt text is most often simply forgotten
Target sizes, contrast and the travelling focus ring
Map framework controls have traditionally been small. WCAG 2.2 sets a floor: targets for pointer input keep at least 24 by 24 CSS pixels unless a listed exception applies (W3C, WCAG 2.2, SC 2.5.8). A level higher lands at 44 by 44 CSS pixels (W3C, WCAG 2.2, SC 2.5.5). This affects more than the zoom buttons: the pins, the close button on the info bubble and the rows of the result list. The most common finding is not an undersized icon but an undersized hit area around it.
On colour, two thresholds sit side by side and are regularly confused. Graphical objects and interface components — pins, cluster circles, focus rings — need at least 3:1 against adjacent colours (W3C, WCAG 2.2, SC 1.4.11). Map labels such as street names and opening hours fall under the text threshold of 4.5:1 (W3C, WCAG 2.2, SC 1.4.3). Low text contrast is the most common failure of all and appeared on 83.9 per cent of home pages (WebAIM Million, 2026); on mobile only 31 per cent of pages meet the minimum contrast (Web Almanac, 2025). Over aerial imagery that becomes an immediate problem: the background changes with every extent. The measurement method is in our article on colour contrast in accessibility.
The third point is the visible focus. 67 per cent of websites explicitly remove the default focus outline (Web Almanac, 2025). In a map-and-list view it is the only feedback about where you stand. WCAG requires a visible focus indicator (W3C, WCAG 2.2, SC 2.4.7) and, since version 2.2, that the focused component is not entirely hidden by author-created content (W3C, WCAG 2.2, SC 2.4.11). How visible focus survives the operating system's contrast mode is covered in our article on forced colors and high contrast mode.
- Measure the hit area of every pin and zoom button, not the icon
- Space neighbouring pins so they stay individually reachable
- Measure marker colours against the actual map tiles, not the design background
- Place map labels on an opaque holder instead of setting text directly on imagery
- Style the focus ring yourself, visible over both light and dark map extents
- Guard sticky bars with scroll margin so the focused entry stays clear
Operating without a mouse: dragging, zooming, panning
Panning is the classic dragging movement, and WCAG 2.2 gives it a criterion of its own: functionality using a dragging movement must also be achievable with a single pointer without dragging, unless the dragging is essential or provided by the user agent (W3C, WCAG 2.2, SC 2.5.7). The standard's explanatory text names the answer and describes a map that can be dragged and additionally offers buttons for up, down, left and right (W3C, Understanding SC 2.5.7). The implementation follows: four directional buttons, two zoom steps, one reset to the initial extent.
Above that sits the older criterion: all functionality must be operable through a keyboard interface without requiring specific timings for individual keystrokes (W3C, WCAG 2.2, SC 2.1.1). For the map that means a clear order. The map surface gets a role and a label and is one stop in the tab order; inside it the arrow keys move the extent and escape returns to the page order. Markers stay out of the tab order because the result list reaches them — otherwise 300 locations would add 300 stops. The patterns are in our article on keyboard navigation in web development.
<!-- Map: one stop in the tab order, markers stay out of it -->
<div class="locator">
<div id="map" role="application" tabindex="0"
aria-label="Map of store locations, arrow keys move the extent">
<!-- Map tiles, markers with aria-hidden="true" -->
</div>
<!-- Single-pointer alternative to dragging (SC 2.5.7) -->
<div class="map-controls">
<button type="button" data-pan="north">Move view north</button>
<button type="button" data-pan="south">Move view south</button>
<button type="button" data-pan="west">Move view west</button>
<button type="button" data-pan="east">Move view east</button>
<button type="button" data-zoom="in">Zoom in</button>
<button type="button" data-zoom="out">Zoom out</button>
</div>
<!-- Equivalent text alternative (SC 1.1.1) -->
<h2 id="results-title">Stores near you</h2>
<p id="results-status" role="status">4 stores within 100 km</p>
<ul aria-labelledby="results-title">
<li>
<h3><a href="/stores/hildesheim/">Hildesheim store</a></h3>
<p>Hoher Weg 4, 31134 Hildesheim</p>
<p>18 km away, open today 9 am to 7 pm</p>
<p>Step-free entrance, lift available</p>
</li>
</ul>
</div>
<style>
/* Target size (SC 2.5.8) and visible focus (SC 2.4.7) */
.map-controls button { min-inline-size: 24px; min-block-size: 24px; }
.locator :focus-visible { outline: 3px solid #572899; outline-offset: 2px; }
.locator li { scroll-margin-block: 6rem; } /* SC 2.4.11 */
</style>Announcements that make the map state audible
A map changes silently. Widen the radius from 25 to 100 kilometres and new pins appear; with a screen reader nothing registers unless something is announced. The store locator needs a status line naming the number of results and the search area after every search, filter change and radius adjustment: four stores within one hundred kilometres, sorted by distance. It must already exist in the markup and only change its text; an element created together with the result is often missed by the screen reader.
The second announcement point is the link between list and map. When a list entry is activated, the map moves there and opens the info bubble. Focus has to travel to the new content and return to the originating entry when it closes — the point where many implementations break, dropping focus to the top of the page. The matching patterns are collected in our article on focus management in single-page apps; for the filter bar beside it, see accessible product search with filters.
One announcement per event, not per pin
Reflow, zoom and the mobile reality
Content must be presentable without loss of information or functionality and without scrolling in two dimensions (W3C, WCAG 2.2, SC 1.4.10). The test width is 320 CSS pixels, a 1280 pixel viewport at 400 per cent zoom (W3C, WCAG 2.2, SC 1.4.10). At narrow widths map and list stack instead of sitting side by side, the list reflows, and the controls stay reachable. The map surface may keep its two dimensions because it falls under the exception for content that requires a two-dimensional layout for meaning (W3C, WCAG 2.2, SC 1.4.10). The rest of the module does not.
In practice this reverses the usual order. On narrow devices the search field comes first, then the status announcement, then the result list — the map afterwards, expandable through a button. That serves the most common case first and saves the data cost of map tiles until someone asks. That this group is no edge case follows from the mobile screen reader figure: 93.6 per cent of respondents with disabilities use a mobile screen reader (WebAIM, Screen Reader Survey 10).
A test plan that actually reaches the store locator
WCAG 2.2 was published as a recommendation on 5 October 2023 and brought 9 additional success criteria compared with WCAG 2.1 (W3C, WAI). Three hit maps directly: dragging movements, target size and focus not obscured. The overview is in our article on the new criteria in WCAG 2.2; formal sign-off then runs through a WCAG audit with a keyboard and screen reader pass.
- Put the mouse away and walk the route once: search field, radius, filters, first result, detail page, directions.
- Check every stop for a visible focus ring over light and dark map extents.
- Measure the hit areas of zoom buttons, pins and list rows against 24 by 24 CSS pixels.
- Measure marker contrast against the real map tiles, not the design background.
- Operate the map without dragging: directional buttons, zoom steps, reset.
- Zoom to 400 per cent and check that only the map surface stays two-dimensional.
- Listen with a screen reader for the result count, search area and sort order.
- Block the map or decline consent and check that the list still carries the task.
Location data that does not lead nowhere
Accessibility does not end at the markup. A pin pointing at a closed branch is a dead end for everyone, and an expensive one for people with limited mobility. Retail networks move fast: for the end of 2026 the German retail association expects 296,600 stores in Germany (HDE, 2026), down from 366,800 stores ten years earlier (HDE, 2026). In the current year alone the forecast has 4,900 stores disappearing (HDE, 2026).
Data quality also covers the fields that decide whether a journey is worth starting: step-free entrance, lift, accessible parking, door width, hearing loop, assistance dogs welcome. These fields belong in the same record as address and opening hours and can be offered as filters, so the search answers a question that previously required a phone call. Our article on accessible intranets and internal systems explains why the internal editing screens carry the same requirements as the public output.
What the rebuild returns
The size of the group concerned is known and still underestimated. At the end of 2025 a good 7.8 million people in Germany had a severe disability (Federal Statistical Office, 2026), which is 9.4 per cent of the population (Federal Statistical Office, 2026). Across Europe the Commission puts the figure at around 87 million people with a disability (European Commission, 2025). For low vision and blindness the German federation estimates roughly 1.2 million people affected (DBSV, 2005); official statistics record a lower bound of 71,260 blind people (DBSV, 2021) and 440,645 people with low vision (DBSV, 2021). Worldwide at least 2.2 billion people live with a near or distance vision impairment (WHO, 2026).
The technical surveys rest on a broad base: the crawl behind the Web Almanac covers 17 million websites per month (Web Almanac, 2025). A list with written-out addresses, opening hours and access details is also the part of the page search engines process best. Technical sign-off combines a screen reader test and a structured review of accessible web development.
A map that gets nobody to the store is decoration. Only the list beside it turns the graphic into information every person can read, hear and operate.
The rebuild is smaller than it looks. In most projects the location data already exists in structured form; missing is the second output beside the map and a handful of rules for target sizes, contrast and focus handling. The result is a module that survives an audit and a route into the store that does not depend on how someone operates a device.
Sources and studies