Maps & Data Visualizations Accessibility: Charts, SVG, Colorblindness

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.

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. 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. 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. 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. 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.

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 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 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. 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 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. 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. 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. 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 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. 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-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. 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. 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. 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 (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. 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. 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. Accessible SVG structure:

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. 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. 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.

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. 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. 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. 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.

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? Tab through all interactive elements. Can you access tooltips? Can you select data points? Is focus visible? Can you exit interactions? Use Coblis or Color Blind Pal to preview visualizations through different color blindness types. Ensure data is distinguishable without color. Test charts on small screens. Are they readable? Are touch targets large enough? Can you scroll to see all content?

Powerful open-source charting library. Not inherently accessible—requires careful implementation. Can create accessible charts with proper ARIA and semantic markup. Simpler charting library. Canvas-based (less accessible than SVG). Requires manual ARIA setup. Good for simple charts. Commercial charting library with built-in accessibility features. Includes screen reader support, keyboard navigation, and data table exports. Charting library with accessibility features. Interactive charts with keyboard support and accessible legends. Open-source charting library with accessibility support including keyboard navigation and screen reader features.

Keyboard controls (Tab, arrow keys, Enter). Screen reader labels and descriptions. Focus indicators. Touch targets 44×44px minimum. Accessible alternatives (location list, search). Accompanying data table. Text description of key findings. Color not as sole means of conveying information. Sufficient contrast between colors. Labels and legends. Screen readers, keyboard navigation, color blindness simulation, mobile devices, zoom at 200%.