How do I make a web map WCAG accessible?

Meet WCAG 2.1 AA: ensure 4.5:1 text contrast and 3:1 for UI and graphical objects, never rely on color alone, make all controls keyboard operable, expose state via ARIA, and provide a data table or text summary as an equivalent alternative.

Which color ramps are safe for colorblind users on maps?

Use perceptually uniform, colorblind-safe ramps such as viridis, cividis, or ColorBrewer schemes flagged colorblind-safe. Avoid red-green for sequential data, and reinforce hue with lightness, texture, or labels so categories survive simulated deuteranopia and protanopia.

How do I make an interactive map keyboard navigable?

Ensure pan, zoom, and every control are reachable by Tab and operable by Enter/Space/arrow keys, give features a focusable representation, manage focus order, and provide a visible focus indicator with at least 3:1 contrast.

How do you provide a text alternative for a map?

A decorative map can be marked aria-hidden, but a data-bearing map needs an equivalent: an accessible data table, a downloadable dataset, or a concise text summary of the patterns, plus alt text describing the map's purpose and key finding.

Accessible Technical Maps: Color, Contrast, Keyboard

Short answer

An accessible technical map meets WCAG 2.1 AA on three fronts at once: perception (colorblind-safe ramps, 4.5:1 text contrast, 3:1 for graphical objects, never color alone), operation (full keyboard control with a visible focus indicator), and an equivalent text alternative (a data table, downloadable dataset, or written summary) for anyone who cannot use the visual map. Geological and terrain maps are harder than typical web content because the data is the color, so you carry meaning redundantly — hue plus lightness plus pattern plus label — and you give the underlying numbers a non-visual path.

This is not a cosmetic pass. A choropleth of alteration intensity or a slope-class map that relies on a red-green ramp is unreadable to roughly 1 in 12 men, and an interactive map that only responds to a mouse excludes keyboard and switch users entirely.

Color: the part technical maps get wrong most

Sequential and diverging data ramps must be perceptually uniform and colorblind-safe. Prefer viridis, cividis, or magma for sequential data, and ColorBrewer schemes explicitly flagged colorblind-safe (e.g. RdYlBu for diverging, YlGnBu for sequential). The classic rainbow/jet ramp fails twice: it is not perceptually uniform (it invents false boundaries in the green-cyan band) and its red-to-green span collapses under deuteranopia.

Practical rules:

Never encode meaning in hue alone. Pair hue with lightness so the data still reads in greyscale; that single test predicts most colorblind outcomes. Print the map in greyscale or run a desaturate filter — if classes merge, so will they for some users.
For categorical layers (rock units, land cover), keep palettes to ~7–8 distinguishable classes and reinforce with texture, hatching, or direct labels. Geological maps have a long tradition of overprint patterns precisely for this reason.
Simulate. Tools like the Coblis simulator, the colorblindness JS filters, or QGIS's Color blindness preview (View > Preview mode) show deuteranopia, protanopia, and tritanopia.
Contrast for graphics. WCAG 2.1 SC 1.4.11 requires 3:1 contrast for graphical objects and UI components (legend swatches against background, line strokes, focus rings). Body text and labels need 4.5:1 (SC 1.4.3); large text needs 3:1.

Operation: keyboard and focus

Most JS map libraries are mouse-first. To satisfy SC 2.1.1 (Keyboard) every action must be reachable without a pointer.

Pan and zoom by keyboard. MapLibre GL JS supports keyboard interaction (arrow keys pan, +/- zoom) when the canvas is focusable — confirm the container has tabindex="0" and is not trapping focus.
Map controls (zoom buttons, layer toggles, legend, search) must be real focusable <button>/form elements in a sensible Tab order, operable with Enter/Space.
Provide a visible focus indicator with ≥3:1 contrast (SC 2.4.7). The default browser outline is acceptable; do not outline: none without a replacement.
For features users must interact with (clickable points, polygons), the canvas alone is not focusable per-feature. Mirror features as a focusable, ARIA-labelled list or use a library feature-layer that emits DOM nodes, so a keyboard user can step through and read each one.
Avoid keyboard traps (SC 2.1.2): a popup must be dismissible with Escape and return focus to its trigger.

Programmatic meaning: ARIA and structure

A <canvas> is opaque to assistive technology, so describe it:

Give the map container role="application" or role="region" with an aria-label ("Slope classification map, study area"). role="application" tells screen readers to pass keystrokes through — use it only when you have implemented full keyboard interaction.
Announce dynamic changes (layer switched, feature selected) via an aria-live="polite" region so non-visual users hear state changes.
Make the legend a real, readable component (a <ul> of swatch + label), not an image, so it is in the accessibility tree.

The text alternative — non-negotiable for data maps

WCAG SC 1.1.1 requires a text equivalent for non-text content. For maps, "decorative" and "informative" diverge sharply:

A purely decorative basemap can be aria-hidden="true" with an empty alt.
A data-bearing map needs a genuine equivalent. The strongest is an accessible data table of the same features/values (sortable HTML <table> with <th scope>), plus a downloadable dataset (CSV/GeoPackage). Add a concise written summary of the spatial pattern ("Highest clay-alteration index in the NW quadrant, decreasing SE"). Alt text on the map states purpose and headline finding, not coordinates.

This dual approach also serves search engines, low-bandwidth users, and anyone who wants the numbers rather than the picture.

Worked checklist for a slope-class web map

Replace any rainbow ramp with viridis (sequential) and confirm class breaks are visible in greyscale.
Run a deuteranopia simulation; if two classes merge, add hatching to one or relabel.
Verify legend text ≥4.5:1 and swatch borders ≥3:1 against the panel background.
Tab through the page: canvas focusable, arrow-pan works, zoom buttons and layer toggles reachable, focus ring visible.
Add role="region" + aria-label, an aria-live status line, and a real HTML legend.
Publish a sortable data table and a CSV download; write a one-paragraph pattern summary and map alt text.
Test with a screen reader (NVDA/VoiceOver) end to end.

Common pitfalls and why they happen

Red-green slope/risk ramps. Chosen because they read as "good/bad," but they are the worst case for the most common color vision deficiency. Use diverging colorblind-safe schemes with a light midpoint.
Color-only categories. Designers assume legend lookup is enough; it forces constant back-and-forth and fails in greyscale. Add patterns/labels.
Mouse-only popups. The library's default click handler has no keyboard equivalent, silently excluding keyboard users. Mirror to a focusable list.
Canvas with no alternative. The map "looks accessible" because controls are styled, but the data has no non-visual path. Ship the table.
outline: none for aesthetics. Removes the focus indicator and breaks SC 2.4.7.

QA / validation

Combine automated and manual checks. Run axe-core or Lighthouse for contrast and ARIA wiring, but neither can judge color semantics or keyboard task flow — do those by hand: greyscale + colorblindness simulation of the rendered map, a full keyboard pass with the mouse unplugged, and a screen-reader walkthrough that confirms a non-visual user can reach the same conclusion as a sighted one.

Bathyl perspective

We design technical maps so the data survives the loss of any single channel: remove color, remove the mouse, or remove sight, and the finding is still reachable. Accessibility and scientific clarity pull in the same direction — redundant encoding and an honest data table make a map both more inclusive and more trustworthy.

Accessibility for Technical Maps