We are continuously researching and developing methods to make our maps accessible to all our users. Considerable work remains to be done, and all producers of web maps around the world are grappling with this to varying degrees. We follow general best practices whereever possible, and focus our accessiblity efforts on both interactivity and visual design. We touch on these areas in the sections below. In the last section, we provide links to online documentation that has helped guide our work. We are continuing to develop the content on this page and will be updating it periodically.
A description field is required for all maps built with NPMap. When accessed with a screen reader, the this text acts like alt text for an image, explaining the purpose of the map to the user.
The current version of NPMap, version 4, is built on top of Leaflet, and incorporates many features from Mapbox GL JS. The next version of NPMap, which is currently under development, will be based on MapLibre. Some of NPMap’s accessibility features originate with the libraries it is built upon, and we provide some details below specific to Leaflet.
NPMap also maintains standard HTML accessibility best practices, like using ARIA (Accessible Rich Internet Applications) tags by default.
NPMap preserves Leaflet’s tab indexing, which enables keyboard operability and provides accessibility to persons who cannot use a pointing device.
To learn more, visit Leaflet’s page detailing their accessibility features.
We use simulators, including Adobe Illustrator’s proof setup/color blindness tool, to help us optimize the visual design of our maps for all users, including those persons who have difficulty discerning colors. Where possible, we don’t rely solely on color to convey different classes or categories of map features. We use additional visual variables, including line patterns, textures, labels, and our robust pictorgraphic symbol set, among others.
Where possible, we employ high contrast in our map symbols to boost legibility for persons with low vision disability. The Slate version of our basemap works well for those low vision users who invert the colors of their screens to boost readability.
The following items are currently queued up in our development backlog:
Map Descriptions for maps in Plan Your Visit pages: We will add an element to the nps.gov CMS where web authors can write descriptions for the maps that appear on their Plan Your Visit pages.
Dynamic Feature Summary: Along with a description of the map shown, we will provide a dynamically-populated summary of the types and counts of features displayed in the map, which allows a person using a screen reader to determine whether to explore the map further and with which accessibility features enabled. The goal is to try to handle situations where a map might have hundreds of interactive points which might theoretically be in the tab-order, but which would functionally be really difficult to deal with for a keyboard-only user. If the user was initially prompted with some info and selections (e.g., to only put certain types of content, such as Visitor Center pins) in the tab order, it might make the map more usable.
Link to data downloads: We will modify our map building tool to prompt map builders to include links to their hosted data. We will then modify the map interface to expose those links to the map user. The goal is to provide an alternative version that the user might find easier to use (e.g., a table view of data); this is also more broadly useful, for third parties that want to take our data and use it for their own purposes.
Tabular data view in map: We’ll create a tabular view of data displayed in the map that can be toggled on/off. Similar to the item above, this provides an alternate means of interacting with the data. In this case, the table can be viewed without first downloading the data.
Focus state display settings: We’ll revise the display settings for focus states when users tab to map UI components, like the home button and the zoom buttons. Right now, a white outline briefly appears before disappearing, which is difficult for persons with low vision to see.
Augmented guidance for map builders: We will augment our internal NPMap guidance to
These items are also on the horizon:
Support a minimum 14px font size for all map labels.
Develop and deploy accessibility plugin for NPMap5 (see details below).
The tool’s options are listed below.
export interface AccessibilityOptions {
'labelField': string | ((feature: GeoJSONMapFeature) => string), // The field to use for the label
'drawFeature'?: boolean, // Will Draw a line around the feature, otherwise will make a bbox
'bufferPixels'?: number, // The size of the line buffer in screen pixels
'bufferSteps'?: number, // The amount of points in the buffer circle (defaults to 8),
'simulateHover'?: boolean | ((feature: GeoJSONMapFeature) => void), // Simulates the mouseover event on focus
'simulateClick'?: boolean | ((feature: GeoJSONMapFeature) => void), // Simulates the mouseclick event on space, enter, or numpad enter
};
The plugin draws an image map-type element on top of the map with a link for each map feature. With a label field specified, the plugin labels the feature:
if (label) {
area.tabIndex = tabIndex;
area.ariaLabel = label;
area.ariaLabel ? area.alt = area.ariaLabel : true;
};
World Wide Web Consortium (W3C) guidance:
W3C Accessible Rich Internet Applications (WAI-ARIA) 1.3
Helpful blogposts and articles that synthesize the available guidance and provide implementation strategies:
Geomatics Canada: How to make maps accessible?
Peer-reviewed research:
Color Design for the Color Vision Impaired, by Bernhard Jenny and Nathanial Vaughn Kelso