A plan for accessible mapsBenjy Stanton on 28 November 2020
Designing accessible interactive maps is hard. I don’t think I could point to any single thing that I’ve worked on that covers all of the things mentioned here. But, if I was going to start a brand new project, with plenty of time to get things right, this is where I’d start.
The following isn't perfect, I'm really just sharing my workings so far. I hope that if you can see something is wrong or missing, you'll point it out. I’ll definitely iterate and add to this post in future.
Accessible map overview
- First, decide if you really need a map
- Make sure information in the map is available elsewhere
- Keep the map simple
- Design the map in black and white first
- Follow web best practice (semantic HTML, progressive enhancement)
- Break the map down into layers (features, dialogues, controls, backgrounds, supporting information)
- Test the map with different browsers and devices including mobiles and keyboards
First, decide if you really need a map
Maps are complicated, both for the people using them, and the teams building them. Do user research to make sure you really need a map.
Make sure information in the map is available elsewhere
It's useful to remember that maps, no matter how well done, are an exclusive tool. They require digital literacy, geographic literacy and they rely on visual communication methods to present information. So they shouldn't be relied upon solely to communicate information to your users.
- Think of maps as an enhancement to the service your building, the core content and functionality should be available without the map
- Make sure that any information available via the map is also available via another accessible route (for example, in a nearby bit of text or data table, or in a downloadable spreadsheet)
- Users of geospatial data might need to download the data in GeoJSON or Shapefile format so they can analyse it with GIS (geographic information system) software
Keep the map simple
- Break content down into multiple pages or sections that meet specific needs, rather than having a single map that contains all of the things
- Avoid complex interactive maps if you don’t need them, for example a static inline SVG might be enough in some cases
- Don't add panning and zooming and multiple layers if you just need to display a single area and its boundary
Design maps in black in white first
Don’t use colour alone to convey meaning. Using red and green to convey "good and bad" without labels is a classic bad example of this. I find that designing in black and white first helps me to do this, then I add colour later, as an enhancement.
- Directly label things where possible, or use a separate legend or key, if direct labelling is not possible
- Consider using shading or cross-hatch patterns instead of colour fills
- Consider using unique line styles, for example dotted or dashed lines
- Use high contrast colours clear enough to read (avoid light greys)
- If legends/keys are used, make sure they work in black and white too
Break the map down into layers
Interactive maps are made up of multiple layers:
- features (points or areas of interest)
- dialogues (for detailed information)
- controls (for example zoom buttons)
- background maps
- supporting information (for example small print)
I like to break down the map, then think about how to make each layer more accessible.
It may be very hard to make maps 100% accessible for everyone, but by considering each component part I think there is plenty of room for improvement and reasonable adjustment.
Features (points or areas of interest)
Features are the points of interest on the map. The individual data points that users are most interested in. They could be points that mark the location of a town, a line that follows the path of a river or a polygon that maps the outline of a local authority. Often they'll have short text labels that are always visible.
- Interactive lines (for example rivers or roads) should be thick enough and high contrast enough to see
- Interactive elements should be large enough to click on
- You can add clickable labels to lines if the lines themselves are so thin they are hard to tap or click on
- Allow users to zoom in, so that selecting the area they need becomes easier
- Make sure interactive elements have clear affordance or example, if a label is a link to new page, style it to look like a link (blue and underlined) and use semantic HTML (
<a>instead of a
- Add clear hover style for interactive elements, for example change the line thickness, tint and mouse cursor
- Any interactive elements of the map should have a clear focus style
- If elements are not interactive, they should have a different visual treatment (for example black and white text without an underline)
Dialogues (for detailed information)
A benefit of interactive maps is that you can progressively disclose details when the user needs, so they don't get bombarded with everything all at once.
- Avoid using tool tips that only appear on mouse hover
- Dialogues need to be keyboard accessible too
Map controls are the buttons, form elements and gestures that the allow users to manipulate how they view the map.
- Common controls include the ability to zoom and pan the map
- Test to make sure these controls are available to all input types, for example mouse, touch, keyboard and voice
- Use visible text labels, not just icons, for less common controls like toggling full screen mode
- Make sure to follow best practice for web forms when adding custom controls (like adding a select menu to change the background map layer)
The background map contains extra context. They typically depict large water bodies, land masses and can include labels for important landmarks like cities.
The images might be generated from satellite photos or they can by stylised illustrations that are common in things like Google Maps.
If you have control of the background layer it’s worth simplifying things down to exactly what you need.
- Turn off any background layers you don’t need, for example hide roads if your users don't need to see them
- Make the text legible, for example increase size and contrast of labels for towns and cities
- Choose background tiles that don’t contrast too much with the foreground layers
Supporting information, map metadata and descriptive labels
Supporting text such copyright, source and license information is often overlooked in maps.
- Make sure the text has sufficient size and contrast
- Make sure links are styled to look like links
- Icons, elements and sections need to have accessible text labels
Test the map with a mobile
- Don't rely on complex motions or gestures
- The doing a basic accessibility check if you cannot do a detailed one from GOV.UK explains this in more detail
- Make sure users don't accidentally zoom into the map, when they meant to scroll down the page
- Test maps still work at small sizes
- Test map works with touch interfaces
Test the map with a keyboard
Consider adding a skip link, allowing keyboard users to skip the map completely. Skip link are more commonly used to skip the main navigation, but could be adapted for this purpose too. Read about skip links in the GOV.UK design system.
Make sure to check all interactive elements are available to keyboard users. For example users will need to interact with the map controls (like zoom buttons and full screen toggles) as well as any interactive features like points and polygons.
Do a range of testing
This blog post isn't an exhaustive list of ways to meet all access needs or create something that works with all kind of assistive technology.
It's definetely worth doing your own manual and automatic testing. I've written a bit about manual and automatic accessibility testing before so I won’t go into more detail here.
It's also important to do user research (including with people with access needs) and to get some accessibility experts to audit the finished thing.
- Defra map design standards
- How (not) to make accessible data visualizations, illustrated by the US presidential election by Sarah L. Fossheim
- Maps issue from the GOV.UK design system backlog
- Design Accessible Maps from Phase
- OS Open Zoomstack styles for colour blind users from Ordnance Survey
- Accessible digital map experiences: a mountain climb or a walk in the park? from David Sloan
- What's the best way to mark-up an SVG map? by Benjy Stanton
- A plan for accessible charts by Benjy Stanton
- Map Accessibility from Minnesota IT Services
Services with maps
- MapItUK from My Society
- Search for schools and colleges to compare on GOV.UK
- Flood map for planning on GOV.UK
- Flood warnings for England on GOV.UK
- Alpha local gov service pattern: Apply for a resident's parking permit
- Prototype organisation page from Digital Land
- UK: New COVID cases in the last week from The Guardian
- MSOA Names from House of Commons Library
- Coronavirus restrictions from House of Commons Library
- FixMyStreet from My Society
Map prototyping tools
- My Maps from Google Maps – create basic maps
- Mapbox static map image playground – create realistic static maps for your prototypes
- Mapstarter – convert Shapefiles and GeoJSON to SVGs
- GeoJSON.io – edit GeoJSON in the browser
Cathy Dutton and the interaction design team at Defra, Angharad Stone, Joe Lanman, Simon Everest, John Waterworth, Rob Chambers, Oli Hawkins, ONS digital and Swirrl.
Updates on 7 December 2020
- Added a link to Map Accessibility from Minnesota IT Services via Philip Kiff
- Added a note about Shapefiles via Mike Gifford
- Added a link to Defra map design standards via Cathy Dutton