Maps in services

This guidance is for teams designing and building services that use maps.

What is a map in a service?

A map in a service is a visual, geographic representation that helps users to identify, interact with or communicate spatial information.

Maps in services can be:

• static – an image that cannot be changed by the user, for example as part of a published report on crime rates, or generated by a service based on information provided by a user
• interactive – allows users to change what the map is showing, for example by zooming, drawing areas or routes, changing time periods, or viewing different layers of information

When to use a map

Use a map when it makes identifying or drawing areas easier to do.

Maps help people to:

• identify and confirm an area with or without a postal address
• select, draw, edit and delete areas
• compare areas
• identify a feature within an area, for example a building, tree or road
• identify where features share a boundary

You should also provide an alternative to a map if possible, and it is recommended that this be designed first.

Both the map and the alternative to the map should be tested with users.

When not to use a map

Start with user needs. Maps are complex – understand specifically what your users need that can only be provided by a map.

Consider whether the same information could be provided in another format, such as a table, address search or data download. Designs for these alternatives should be explored before, or alongside, designs for a map.

Choosing the right type of map

To choose a type of map you must first understand the user needs for your service.

The map type you choose depends on the data you need to show. Common purposes for maps in services include:

• presenting spatial information, for example points of interest, areas or line features
• creating new or editing existing spatial data
• route finding
• data visualisation, for example choropleth or dot density maps

Static maps

A static map is an image that cannot be changed by the user. For example, a static map may be:

• part of a published report on crime rates
• generated by a service based on information provided by a user

Interactive maps

An interactive map allows users to change what the map is showing. For example, an interactive map may allow users to:

• zoom to show a larger or smaller area of the map
• plot a route or area
• draw areas or routes on to the map
• change the time period shown
• view different layers of information

Alternatives to maps

Always consider whether there is a more accessible or simpler way of achieving the same goal as a map.

Alternatives to a map could include turning geospatial data into textual data, for example:

• describing the area and orientation
• showing the postcode based on the map coordinates
• using other geographic data such as address, postcode or IP address to direct relevant information to the user

Other map alternatives could include:

• providing data in other formats, such as GeoJSON or a downloadable spreadsheet
• a search and filter function

Accessibility

Maps are exempt from the Public Sector Accessibility Regulations 2018, but you should still do as much as you can to make your map accessible. Public sector organisations must also meet their responsibilities under the Equality Act.

There is no comprehensive list of how to make a map fully accessible. Test with your users to identify which areas you need to prioritise.

Introducing and explaining the map to users

• Show one thing per map – do not try to make one map do too much
• Have a clear explanation of what the map is and how to use it on the surrounding page
• Use plain English for all content on the map

Making the map itself more accessible

• Make sure your map is keyboard accessible – use standard controls and allow small and large step navigation
• Ensure colours contrast highly enough with the basemap and with each other
• Consider colour vision deficiency and set a minimum font size
• Use ARIA attributes and ensure compatibility with screen readers
• When using sequential colouring to visualise data, ensure there is a query function that allows the user to check the data through clicking or hovering
• Give users a choice about how to display the map, for example being able to choose their preferred basemap
• Where vector tiles allow, use solid colour for map layers above a basemap, and bring basemap taxonomy above any solid data layers to show map details beneath
• Consider providing different stylesheets for different needs, for example colour vision deficiency, low contrast or high contrast
• Consider translations, for example English and Welsh
• Ensure the map works on a responsive website across mobile, tablet and desktop

Map colours

Present map features in different colours or shading, such as:

• black and white
• high colour contrast (aim for WCAG AAA compliance)
• hatching

You can use or copy colour schemes developed specifically for this purpose from trusted sources such as Ordnance Survey. Check the use case is the same as yours.

See the following examples of map colours:

• ESRI guide to designing maps for colourblind readability
• Ordnance Survey maps example where the colour palette can be chosen
• Office for National Statistics choropleth census maps

Ordering pages, map elements and options

Organise the order of pages in the service and the order of elements on the page, for example:

• placing a postcode search first
• using a map after a textual address, so that the map is not the primary element if it does not need to be

You can organise the interactive map options in the most usable order, for example:

• have the search and filter tools earlier in the tab order than the map
• investigate separating map controls into basic and advanced options
• present customised help, such as keyboard controls

Alternative ways to interact with the map

Explore interacting with the map in other ways, for example:

• keyboard
• voice
• filtering, refining a search, or removal of map features

For mouse and touch screen, ensure that touch targets are large enough.

Using a keyboard

Make map options accessible by keyboard, including:

• ensuring the controls can be tabbed to
• that they are in a logical tab order
• investigating methods for selecting features or drawing a boundary, for example using Web Feature Services (WFS) and selecting a feature at the centre of the map

Common key mappings are:

• arrow keys for panning
• the + and - keys for zoom
• enter or space to select

Key controls, zoom and vector map tiles

Consider including a toggle to show or hide the key controls.

Some JavaScript libraries handle zoom slightly differently. Most zoom the map when the =/+ key is pressed without the need to use the shift key. OpenLayers does not do this and the functionality would need to be added.

Use vector map tiles instead of static images.

Textual and semantic elements

Present map options in textual form, this includes:

• using labels instead of icons
• not putting text in images

Add textual descriptions to visually presented elements.

Use the correct semantic elements, including:

• button HTML tags for buttons, not other tags
• GOV.UK Design System components instead of custom ones

Add additional semantic data to elements, including:

• metadata such as microdata or microformats
• HTML attributes or ARIA attributes

Remove or reduce the amount of JavaScript

Provide a no-script version of the map if JavaScript is unavailable to the user.

Technical considerations

Choosing a basemap

Consider what basemap best suits your users' needs. Basemap options include WMTS or vector tile services (VTS). When using OS data in the public sector, consider the Public Sector Geospatial Agreement (PSGA).

Choosing a map library

There are a number of open source and commercial map libraries available, including Leaflet, OpenLayers, Mapbox and ESRI ArcGIS. The choice of library will affect the cost and functionality available to your service.

Boundaries and data

When using boundaries in your map, consider:

• where to get boundaries from, for example local authority boundaries, regions or points of interest from open data libraries
• how to optimise boundaries for performance
• how many boundaries to show at one time
• how to keep data pipelines maintained and up to date

Importing and exporting data

Let users download the data from the map where possible. Consider including a data catalogue that includes sources of the data and any caveats.

Consider what data formats to support for import and export, for example GeoJSON or CSV.

Map titles, legends and symbols

Consider what someone needs to know about the map before they look at or use it. This includes:

• a clear map title that describes what is being shown
• a legend, explaining what map features represent
• copyright attribution, placed in an appropriate location
• whether a north line is required
• information about the data being displayed, including its source and when it was last updated

How to test your map

Start with a discovery to find out what map solutions exist, define the problem and gather stakeholder and user requirements.

Carry out user research to gather user needs, including what interactions users have with maps and what their digital skill level is.

Test both the map and any alternatives with users. Accessibility testing should also be carried out.

What you would need to demonstrate at a service assessment may include how you have approached accessibility, user testing and the use of map alternatives.

Get help using maps in your service

Speak to teams with maps in their services.

Collaborate with government designers on maps. Visit:

• UK Government Digital Slack – Maps in services channel

Learn from other government departments' maps guidance. View:

• GOV.UK Design System backlog: Maps
• Scottish Government Design System – Maps guidance
• DEFRA public wiki page on using interactive maps
• DEFRA Design standards for maps
• DEFRA blog post: Designing a more accessible flood map
• Digital Land – Map component
• Transport for West Midlands – Map style
• HM Land Registry Design System – Maps guidance

Ordnance Survey Labs contains tools and information for using maps.

The GeoDataViz Toolkit contains sections on:

• using the right basemap
• cartographic design principles
• using colours

Help us improve maps and this guidance

This guide was developed collaboratively by a cross-government maps working group.

If you have feedback on how we can improve this guide, or examples of maps in services you would like to share, please get in touch via the Maps in services Slack channel.