Maps are powerful tools that help us understand our world, explore our surroundings, and make informed decisions. Yet for many people, online maps can be difficult or impossible to use when accessibility is not considered during design and development. Accessible mapping helps ensure everyone can navigate and benefit from geographic information.

In May, we launched our new WCAG 2.1 role based materials, including a dedicated page for Maps/Geospatial Information Science (GIS). This article builds on that work by exploring how WCAG 2.1 applies to maps, sharing key insights we learned during our Global Accessibility Awareness Day (GAAD) 2026 event, and highlighting new resources that can help your agency improve map accessibility.

A look back: Navigating a map with a screen reader

During our GAAD event on May 21, 2026, attendees heard a live conversation between a screen reader user and a GIS developer about the challenges and opportunities of making web maps accessible to everyone. Together, they demonstrated what happens when a screen reader interacts with a modern web map. The result offered a candid and sometimes surprising view into how map interfaces work—and where they struggle—for blind and low‑vision users.

Key moments from the discussion

Screen readers read linearly—maps don't.

Screen readers move through content in a logical reading order, but maps often distribute information across multiple visual regions. When the two come together, users may hear:

• Unlabeled graphics
• Repeated category names
• Out-of-order information
• Popups that appear visually but not programmatically

The demo revealed how a map's design choices directly influence the way assistive technology understands and announces the content.

Orientation matters.

Different screen readers give different clues about where the user is on the page. Without consistent cues, map navigation can feel like wandering without landmarks.

Keyboard navigation rarely "just works."

Many map interactions rely on mouse‑only events like clicking or hovering. The developer shared examples of the custom code needed to simulate clicks from the keyboard and surface the underlying data in a meaningful way.

Status messages make a difference.

When the map announced "You are panning north" or "Search complete," it created a more predictable experience. These small confirmations gave the user a sense of control.

Audience questions raised important themes.

Participants asked about:

• Splash screens that block the map.
• How to label legend items so assistive technology can interpret them.
• Whether Esri's map templates support accessibility.
• How can non-developers build simpler, more accessible maps.

You can review the Q&A's in our GAAD 2026 Recap article.

Introducing the WCAG 2.1 & Maps/GIS and Role-Based page

If you work with maps, GIS applications, or spatial data—even occasionally—the Maps/GIS role-based resource page is designed for you.

This resource breaks down how each WCAG 2.1 success criterion applies to maps in plain language and provides practical examples. You'll find:

• What does each WCAG 2.1 success criterion mean for map creators.
• Guidance on making map layers, legends, buttons, and forms and other interactive elements accessible.
• Implementation tips for Esri platforms and custom applications.
• Examples showing correct and incorrect labeling.
• Links to additional training and resources.

Note: These role‑based pages were originally created to help State of Minnesota employees prepare for the updated state standard from WCAG 2.0 to WCAG 2.1, which is why they focus specifically on the twelve new WCAG 2.1, Level A and Level AA success criteria.

Whether you create, maintain, or publish maps, this resource provides practical guidance for GIS professionals, developers, content authors, communications teams, and others who use maps to communicate with the public.

How WCAG 2.1 helps improve map accessibility

While the Maps/GIS page covers all 12 new criteria in WCAG 2.1, several stood out during the GAAD demo and audience discussion.

Identify Input Purpose (SC 1.3.5)

Search bars and form fields are common in map applications. When fields are correctly identified:

• Assistive technology can communicate the purpose of the input.
• Users understand what type of information they should enter.
• It supports autocomplete tools.

Reflow (SC 1.4.10)

Maps often include toolbars, legends, and popups that must stay usable at 400% zoom. Make sure:

• Buttons don't overlap. Responsive design supports this.
• Popups stay on screen.
• Legends don't break or compress in unexpected ways.

Focusing on flexible layouts helps maps remain usable across devices and settings.

Label in Name (SC 2.5.3)

This criterion ensures that the visible text label matches the programmatic label used by assistive technology. Why it matters:

• Screen readers can announce "unlabeled graphic" in the map, including the map legend.
• Mismatched labels confuse both screen readers and speech‑to‑text tools.
• Consistent labeling creates predictable navigation.

Status Messages (SC 4.1.3)

Maps are interactive and users need to know when something has changed.

• In the GAAD demo, the screen reader announced panning, zooming, and search completion.
• Status messages help users confirm that actions worked.
• They also help users stay oriented in interactive environments.

Why maps pose unique accessibility challenges

The GAAD Q&A highlighted several themes that map creators should keep in mind:

Maps bundle a lot of information into one visual element.

A map may communicate:

• Landmarks
• Routes
• Patterns
• Spatial relationships
• Layers of meaning

Translating all of that into speech requires thoughtful design and sometimes custom tooling.

Web mapping platforms vary in accessibility support.

Some Esri components handle accessibility well. Others require:

• Custom code.
• Alternative keyboard interactions.
• Additional descriptions or summaries.
• Rethinking the order of content on the page.

There is no single "right way" to make a map accessible.

A map designed for showing clusters of lakes will differ from one that helps users find a permit location. Accessibility must match the map’s purpose.

Where to go next

If you're ready to explore further, we encourage you to continue with the resources introduced in our GAAD 2026 recap article, which includes:

• The event recording
• The full audience Q&A
• Several map accessibility resources

These materials build a strong foundation for understanding why map accessibility matters and how agencies across Minnesota are beginning to improve their map experiences.

Closing Thoughts

Maps are one of the most powerful—and most complex—digital tools we use across state services. As we learned during GAAD and through our work on the WCAG 2.1 role-based pages, accessible maps are built through intentional design, ongoing collaboration, and a commitment to viewing information through the experiences of all users.

We hope these articles helped you deepen your understanding of map accessibility and spark new ideas within your teams. Whether you build maps, review them, purchase them, or simply share them with your communities, you play a role in making spatial information usable for everyone.