Maps & Data Visualizations: Making Complex Information Accessible

Introduction

Interactive maps, charts, and data visualizations are increasingly common on websites. They're also a rapidly growing accessibility barrier and emerging litigation area. Maps without keyboard controls, charts without data tables, color-coded information—these exclude millions of users and create legal liability.

This guide covers everything you need to know about accessible maps and data visualizations: keyboard navigation, ARIA descriptions, color independence, data tables, and SVG accessibility.

Legal Disclaimer

A11yscan is not a law firm and does not provide legal advice. We operate under best practices based on WCAG Guidelines, ADA requirements, and applicable jurisdictions. Courts don't always agree on terms and expectations for web accessibility, and legal standards can vary by jurisdiction. However, an accessible website works better for all users regardless of legal requirements. For specific legal guidance, consult with a qualified attorney specializing in accessibility law.

Interactive Maps: Making Navigation Accessible

Common Map Accessibility Barriers

Interactive maps often rely on mouse clicks for navigation: click to zoom, click markers for info windows, click to pan. Keyboard users can't interact. Screen reader users hear nothing. Touch screen users may struggle with small targets. The result: maps exclude disabled users.

Keyboard Controls for Maps

Users must be able to Tab to the map, then use keyboard shortcuts: arrow keys to pan, +/- to zoom, Enter to select markers, Escape to close info windows. All controls need visible focus indicators. The keyboard interface should be discoverable—help text or instructions should explain available keys.

Screen Reader Accessibility

Map markers, layers, and controls need names and descriptions. Markers should have aria-label attributes: "Restaurant: Mario's Italian at 123 Main St". Layer toggles should have states. The map viewport should have a title. Users should hear what they're selecting and why.

Touch Target Sizing

Map markers and clickable areas must be at least 44×44 CSS pixels. If markers are smaller, make their touch targets larger. Provide alternative ways to access marker information (lists, search) for small or overlapping markers.

Zoom & Text Resizing

Maps must work when zoomed to 200%. Labels should remain readable. Controls should remain accessible. Interactive functionality shouldn't break. Use responsive design principles so maps adapt to screen size.

Accessible Mapping Solutions

Google Maps Accessibility

Google Maps has keyboard controls built-in but not always obvious. Markers need descriptive titles. Add a text list of locations as an alternative to the map. Include search functionality so users can find locations without clicking the map.

Leaflet (Open-Source Option)

Leaflet is an accessible open-source mapping library. It supports keyboard navigation and screen readers better than many commercial solutions. Requires custom JavaScript but offers more control.

Mapbox Accessibility

Mapbox supports keyboard controls and screen reader features. Markers can have accessible labels. Layers can be toggled via keyboard. Test your implementation—not all features are accessible by default.

Best Practice: Providing Alternatives

Always provide an accessible alternative to an interactive map: a list of locations with addresses and descriptions, a table with location details, a search form to find locations. This benefits all users and ensures accessibility even if the map has issues.

Charts & Graphs: Data Visualizations

Why Charts Are Inaccessible

Charts convey information visually: pie charts show proportions, line graphs show trends, bar charts compare values. Screen reader users can't see the visual representation. Colorblind users may misinterpret color-coded data. Low-vision users may not distinguish small distinctions.

Data Tables: The Essential Alternative

Every chart must have an accompanying data table with the underlying numbers. The table is the accessible alternative that conveys the same information. Users should be able to Tab to a "View Data" link that displays the table. The table should be on the same page or easily accessible.

Table Structure for Accessibility

Use proper HTML table markup:

, , , ,
, . Header cells should use with scope attributes (scope="col" or scope="row"). This allows screen readers to announce which row/column each data point belongs to. The table becomes understandable.

Bar Charts Accessibility

Provide: (1) visual chart, (2) data table, (3) text description of key findings. The text description is critical: "Revenue increased 35% year-over-year, from $2.1M to $2.8M." Users don't need to extract this from the visual or table.

Pie Charts & Proportions

Pie charts are inherently difficult to interpret accurately, even visually. Use bar charts instead when possible. If pie charts are necessary, provide a data table and text description. Include exact percentages—don't rely on visual estimation.

Line Graphs & Trends

Provide the underlying data in a table. Include text descriptions of trends: "Performance dipped in Q2 before recovering in Q3." Describe peaks and troughs. Help users understand the story the data tells.

Color & Colorblindness: Accessibility Beyond Charts

Never Use Color Alone to Convey Information

Color-coded systems (red=error, green=success, blue=info) exclude colorblind users. 1 in 12 men and 1 in 200 women have color blindness. Use color plus patterns, labels, or icons. A red error icon with "Error" text works for colorblind users. A red box with no label doesn't.

Color-Blind-Friendly Palettes

Avoid red-green combinations (the most common colorblindness). Use blue-orange, blue-yellow, or blue-gray combinations. Tools like Colorblind Web Page Filter let you preview your design through different color blindness types.

Contrast Within Colors

Even for users with color vision, distinguishing similar shades is difficult. Ensure sufficient contrast between colors in charts. Light blue and light purple are hard to distinguish; light blue and dark purple are easier.

Testing for Colorblindness

Use simulation tools: Coblis, Color Blind Pal, or Spectrum. Preview your visualizations in different color blindness modes. Ask colorblind testers to review. Don't assume your palette works—test it.

SVG Accessibility: Scalable Vector Graphics

What Is SVG

SVG (Scalable Vector Graphics) is a vector format ideal for charts, diagrams, and interactive graphics. SVGs scale perfectly at any size and have small file sizes. But they can be inaccessible if not properly structured.

Making SVGs Accessible

Add title and description elements inside the SVG: Chart Title and Description of chart contents. Add aria-labelledby and aria-describedby attributes. Use semantic elements (text for labels, groups for related elements). Test with screen readers.

SVG Interactive Elements

If SVG includes interactive elements (clickable regions, hover effects), ensure keyboard accessibility: Tab to elements, Enter to activate. Provide focus indicators. Test thoroughly with keyboard navigation.

SVG Code Example

Accessible SVG structure:

<svg aria-labelledby="title desc">
  <title id="title">Q3 Revenue by Region</title>
  <desc id="desc">Bar chart showing revenue for North, South, East, and West regions</desc>
  <!-- Chart content -->
</svg>

ARIA Descriptions for Complex Graphics

Using ARIA Labels & Descriptions

Use aria-label to provide a short label for a graphic. Use aria-describedby to reference a longer description. For complex visualizations, the description should explain the key data and findings.

Long Descriptions

For charts and graphics, include a "longdesc" alternative or an associated text description. The description should convey the same information as the visual: data values, trends, key insights.

Dynamic/Updated Graphics

If a graphic updates dynamically (live data, user interaction), announce changes to screen readers using aria-live. This alerts users to updates without reloading the page.

Geographic Data: Non-Map Alternatives

When Maps Don't Work

Not all users need or want to interact with maps. Some have difficulty with spatial reasoning. Some use phones and small screens where maps are tiny. Some are searching for specific information (nearest location, address) that maps don't provide efficiently.

Provide a Location List

Include a sortable/searchable list of locations with addresses, phone numbers, hours. This is faster for users searching for a specific location. It works on all devices and is naturally accessible.

Combine Map + List

Show an interactive map AND a list. Let users choose: they can browse the map or use the list to find locations. Clicking a list item highlights the marker on the map. This serves all user preferences.

Filtering & Search

Provide filters (by type, distance, amenities) and search so users can find relevant locations without scanning a map. A search form with results is often more efficient than exploring a map.

Testing Charts & Visualizations

Screen Reader Testing

Test charts with NVDA, JAWS, or VoiceOver. Can you understand the data without seeing the visual? Do you hear the title, labels, and data values? Is there a data table alternative?

Keyboard Navigation

Tab through all interactive elements. Can you access tooltips? Can you select data points? Is focus visible? Can you exit interactions?

Color Blindness Testing

Use Coblis or Color Blind Pal to preview visualizations through different color blindness types. Ensure data is distinguishable without color.

Mobile Testing

Test charts on small screens. Are they readable? Are touch targets large enough? Can you scroll to see all content?

Accessible Charting Tools & Libraries

D3.js

Powerful open-source charting library. Not inherently accessible—requires careful implementation. Can create accessible charts with proper ARIA and semantic markup.

Chart.js

Simpler charting library. Canvas-based (less accessible than SVG). Requires manual ARIA setup. Good for simple charts.

Highcharts

Commercial charting library with built-in accessibility features. Includes screen reader support, keyboard navigation, and data table exports.

Plotly

Charting library with accessibility features. Interactive charts with keyboard support and accessible legends.

Apache ECharts

Open-source charting library with accessibility support including keyboard navigation and screen reader features.

Maps & Data Visualizations Compliance Checklist

All Interactive Maps Must Have

Keyboard controls (Tab, arrow keys, Enter). Screen reader labels and descriptions. Focus indicators. Touch targets 44×44px minimum. Accessible alternatives (location list, search).

All Charts & Graphs Must Have

Accompanying data table. Text description of key findings. Color not as sole means of conveying information. Sufficient contrast between colors. Labels and legends.

Test Everything

Screen readers, keyboard navigation, color blindness simulation, mobile devices, zoom at 200%.

Resources & Tools

Key Takeaways

  • Interactive maps must support keyboard navigation and screen readers.
  • Every chart needs an accompanying data table with the underlying data.
  • Never use color alone to convey information—add patterns, icons, or labels.
  • SVGs must have titles, descriptions, and semantic markup.
  • Text descriptions should explain key findings from visualizations.
  • Provide alternatives to maps (location lists, search) for all users.
  • Test visualizations with screen readers, keyboard navigation, and colorblind users.
  • Mobile users and users zooming need accessible chart layouts.
  • Accessible data visualizations benefit all users: faster to understand, available on all devices.
  • Inaccessible maps and charts are growing litigation targets.

Audit Your Data Visualizations

Free scan to identify map and chart accessibility gaps.