​Content contribution: Jason Ewert, GIS Application Analyst, MNIT partnering with the Minnesota Pollution Control Agency, member of the Accessible Maps Community of Practice. 

Maps are visual by nature. But have you ever listened to your map? Imagine that was the only way you could understand a map. Recently, the State of Minnesota’s State Agency GIS Collaborative gave a presentation to state employees about listening to your maps and provided resources from the State’s Accessible Maps Community of Practice (CoP) group. 

This article summarizes that presentation and provides resources to help digital map designers incorporate accessibility into their maps. We have also included information about how the state’s new Digital Accessibility Standard and WCAG 2.1, Level AA impacts digital map design. 

Editor’s Note: A basic understanding of digital accessibility will help to follow along with this article. 

State of Minnesota’s GIS Bytes Presentation Recap: Listen to Your Maps  

The presentation included creative solutions using JavaScript to address web map accessibility issues that make it difficult for screen reader technology to read maps. It included simple tests to check for map accessibility and ensure that any assistive technology including screen readers can properly read digital maps for the user. 

Commonly Missed Accessibility Items

Structure and keyboard accessibility 

Structure allows a screen reader user to understand the framework of the digital content. Keyboard accessibility ensures the content is navigable using only the keyboard, which is often how a screen reader user moves through digital content. Structure adds to keyboard accessibility by allowing users to execute common keyboard shortcuts and have the screen reader jump to the content they are most interested in. 

Example: Use semantic HTML to add headings, paragraph and list elements, as well as main content areas to the map. This adds information into an Accessibility Tree in the Document Object Model (DOM). 

<header> 

<nav> 

<main> 

<h1> 

<p> 

<h2> 

<ul> <li> 

<ol> <li> 

<footer> 

Important map descriptions 

Having proper descriptions for map elements allows a screen reader to understand what is being viewed on the map and to know what is happening, so it can read the information to the user. Description needs include titles, labels and roles for attributes, along with alternative text for images.   

Example: Set the role and title of a div. The name of the div that contains the map is: myViewDiv. 

myViewDiv.setAttribute(‘role’, ‘application’) 

myViewDiv.setAttribute(‘title’, A map of Minnesota showing satellite images. The map displays city boundaries from the search results list’) 

Example: Handling dynamic content for search results, error and success messages, or navigating in an interactive map. You can use ARIA (Accessible Rich Internet Applications) live regions to define dynamic content. ARIA inserts itself into the Accessibility Tree in the DOM. 

resultsDiv.setAttribute(‘aria-live’, ‘polite’) 

Use the ‘polite’ mode rather than ‘assertive’ 

resultsDiv.setAttribute(‘aria-atomic’, ‘true’) 

The aria-atomic setting will re-read the full div, not just the changes made. 

Logical reading order 

It is important to create linear paths (logical element flow) in the structure of the map, along with properly incorporating an after-action item into the flow so a screen reader can properly convey the intention of the map to the user. For example: The user enters search criteria, and the search results popup is the next item in tab order; The user selects a location on the map and the next item in tab order is the details for the selected location. Linear paths also ensure a user does not get disoriented while listening to the information presented by the map through the screen reader.  

Example: Run a search and then send the focus to the search results.  

GetElementById(“searchResults”).focus() 

This requires tabindex >=0.  

Example: Send the user to the new DOM element and then back to the natural flow of elements when they exit (Enter a search item, visit search item popup, close search item popup, and return the user to the search box). 

SearchWidget.on(“search-complete”, () => myFunction()) 

Shift the focus flow to the popup using view.popup.focus() 

On popup close, shift the focus back to the search: once !view.popup.visble => view.search.focus()

Three Simple Accessibility Tests for Maps 

There are a few tools available that allow you to check your maps for accessibility.  

• Hover – A “Hover test” is a quick way to check if your map’s accessible components work as intended. 
  Example: You must be able to control a mouse for this test. When you hover over elements with your mouse and an element has a description popup, then the screen reader will also read it.  

• Keyboard only – Are you able to use your keyboard tab key to navigate to every part of your map? Do keyboard shortcuts create expected behaviors (Enter key makes an action activate, Tab key moves logically between interactive elements and receives focus, Spacebar opens menus and dropdowns). 
• WAVE – Use the WebAIM WAVE accessibility evaluation tool to check your map’s ARIA, structure, and alt text along with other essential accessibility criteria such as contrast and links. 

Map Examples with Accessible Components Added 

• The Minnesota Environmental Quality Board Environmental Review Projects map provides a description of the map, is keyboard accessible (using the Tab key), and provides keyboard access to the project locations’ modals. 
• The Minnesota Pollution Control Agency’s What’s in My Neighborhood map (a demo map created by Ewert) creates logical reading order by setting up linear paths. Using the search term “Quality Bike Products,” the screen reader then reads the proper search results and where the location on the map adjusted to, along with how much it zoomed in. 

What’s New for Map Accessibility with WCAG 2.1 

With the recent update to the state’s Digital Accessibility Standard (as of July 1, 2024), several new success criteria have been added for digital maps. Additional requirements make digital content more accessible for screen reader users. The GIS Bytes presentation included the following tips.  

• 1.3.5 Identify Input Purpose (AA) - This helps assistive technology communicate the purpose of user input fields in alternative ways. 
• 1.4.13 Content on Hover or Focus (AA) - This is particularly relevant for web maps with vector data interactions or an identify tool. As the user selects features on a map either by clicking or hovering, we need to ensure that any pop-ups can be dismissed by pressing escape or by selecting a different feature.   
• 2.5.1 Pointer Gestures (A) - Users who cannot accurately perform path-based pointer gestures - on a touchscreen or with a mouse - will have alternative means for operating the content. This only affects tools where intermediate locations are recorded. 
• 2.5.2 Pointer Cancellation (A) - The objective is to prevent the user from taking an unintended irreversible action based only on a pointer down-event, such as a key press, mouse button press, or touching a control on a screen. 
• 2.5.3 Label in Name (A) - This helps to ensure that the words which visually label a component are also the words associated with the component programmatically. 
• 4.1.3 Status Messages (AA) - Ensures users are aware of important changes in content that are not given focus, and to do so in a way that doesn't unnecessarily interrupt their work. 

Note: The Accessible Maps CoP is updating their accessibility guides for maps to incorporate the new WCAG 2.1 criteria. Watch the Office of Accessibility (OoA) Accessible Maps web pages for updates to the guides for Map Design, Static Maps and Interactive Maps.

Additional Training & Resources for Creating Accessible Maps

• OoA Accessible Maps Training web page  
• OoA Maps Accessibility Quick Reference Cards 
• OoA Article: Maps for All 
• OoA Article: WCAG 2.1 Makes Maps Easier to Use 
• Worldwide Web Consortium’s (W3C) How to Meet WCAG 2.0 Quick Reference web page 
• W3C’s How to Meet WCAG 2.1 Quick Reference web page 
• W3C’s Aria Authoring Practices Guide 
• WebAIM’s How to Build Accessible JavaScript web page 
• esri's ArcGIS Blog: Build Accessibility into your Web Maps with ArcGIS Maps SDK for JavaScript (2024) 
• esri's ArcGIS Blog: Build Accessibility into your Web Maps with ArcGIS Maps SDK for JavaScript and Calcite Design System (2023) 
• NVDA Screen Reader 

For State of MN Employees

• OoA extranet Role-based training for Maps/GIS
• Accessible Maps CoP (MNIT Employees only)