Mapping Meets WCAG 2.1: Minnesota Releases Accessibility Field Notes
Minnesota published a WCAG 2.1 map accessibility guide titled 'What We Learned, and Where to Go Next.' The retrospective covers layered features, keyboard interactions, and ARIA data structures for cartographic products.
- AuthorSophie Lindqvist
- ChannelAccessibility
- Filed
- Read2 min

- Minnesota state government published 'Making Maps Accessible with WCAG 2.1: What We Learned, and Where to Go Next' on mn.gov
- WCAG 2.1 was published by the W3C in June 2018
- WCAG 2.1 added 17 success criteria on top of WCAG 2.0
- Map audits typically test criteria 1.1.1 (Non-text Content), 1.3.1 (Info and Relationships), 1.4.3 (Contrast Minimum), and 2.1.1 (Keyboard)
- WCAG 2.2 added criteria 2.4.11 (Focus Appearance) and 2.5.8 (Target Size) at proposed recommendation stage in 2023
The Minnesota state government has published a new accessibility guide, Making Maps Accessible with WCAG 2.1: What We Learned, and Where to Go Next, hosted on mn.gov. The title signals a retrospective from a state information technology team working on cartographic products.
For designers and developers shipping geographic interfaces, the release lands inside a defined compliance frame. WCAG 2.1, the W3C recommendation published in June 2018, added 17 success criteria to WCAG 2.0. Maps collide with many of those criteria at once, which is why a public-sector lessons-learned document carries weight an internal postmortem cannot.
What does WCAG 2.1 actually require of maps?
Three requirements recur in audits of cartographic products:
- 1.1.1 Non-text Content: layered features need text alternatives that convey the same meaning a sighted reader extracts from color, shape, and label.
- 1.4.3 Contrast (Minimum): text and meaningful graphics against basemap tiles must meet a 3:1 ratio.
- 2.1.1 Keyboard: every interactive map function, including pan, zoom, and layer toggle, must work without a pointing device.
A fourth area shows up when teams run deeper reviews. 1.3.1 Info and Relationships governs how the underlying data structure reaches assistive technology through ARIA roles, tab sequences, and proper heading hierarchies. Most public mapping libraries ship without these hooks by default.
Why does state-level documentation matter here?
Compliance audits can flag a missing image alt in minutes. The same review on a layered choropleth with hover tooltips, drawn polygons, and address lookup can stretch for weeks because each control demands its own pattern. A state agency publishing the criteria it actually tested, alongside the specific failures it found and the fixes it shipped, compresses that timeline for every peer organization that follows.
Public-sector teams also inherit basemaps, demographic overlays, and routing tools from multiple vendors, each with its own keyboard and screen reader model. The patchwork creates cross-component accessibility debt that consultancy reports address at a price few municipal teams can justify.
What should practitioners extract next?
The Where to Go Next half of the title suggests the Minnesota team has left gaps on the table rather than declaring victory. Practitioners tracking the WCAG 2.2 draft, which added criteria 2.4.11 (Focus Appearance) and 2.5.8 (Target Size) at proposed recommendation stage in 2023, will read any forward-looking statement in the document as a procurement signal.
Until the guide's full text circulates, teams shipping maps in 2024 should treat Minnesota's publication as confirmation that WCAG 2.1 now operates as the working floor for state accessibility programs, with WCAG 2.2 criteria queued behind it.
Source: Google News: WCAG accessibility
More from Sophie Lindqvist
Show full bio
Staff writer covering people, launches and day-to-day practice in Product and interaction design, design systems at Interface Wire.
64 articles