Making interactive Maps accessible

This article focuses on interactive map services and how they can be made accessible. Interactive maps play an increasingly important role today. While simple map snippets may only require alternative text, complex interactive maps are frequently embedded. These might display branches, locations, or other points of interest. They are also used in public transport to show stops and routes for buses and trains. It is no longer just about simple directions, but about providing extensive information; therefore, accessibility is crucial in this context.

Maps are inherently helpful tools. Thanks to services like Google Maps, many people are accustomed to using them for orientation. For sighted individuals, they offer a quick overview, allowing them to instantly see how many stops are nearby and where they are located—information that can be grasped at a glance.

For blind people, however, the accessibility of maps is limited due to the way information is presented. Blind individuals receive information in a linear sequence—one item after another. Consequently, navigating a two-dimensional layout involving horizontal and vertical relationships—as maps require—is significantly more difficult. There are limits to how this constraint can be overcome; I will discuss potential solutions in more detail later.

Visual Accessibility

First, let’s look at visual accessibility. Non-textual elements—such as roads or markers for bus stops, branches, and other points of interest—require a minimum contrast ratio of 3:1 against the background. Text on the map, such as street names or stop designations, must meet a higher standard of at least 4.5:1.

In practice, this often presents a challenge. Standard map displays from services like OpenStreetMap or Google Maps frequently fail to meet these requirements. A high-contrast mode offers a good solution: users can activate a high-contrast map view via a button, while the map itself is simultaneously simplified. Less important details can be hidden. For instance, someone looking for a bus stop generally does not need a detailed depiction of parks or other background information. This makes it easier to maintain the necessary contrast levels and improves overall clarity.

High-contrast mode should also function reliably under various conditions. Many map services, for example, offer a night mode that adjusts the display for dark environments. The required contrast levels must be maintained in this mode as well.

Another important aspect is the map markers. These indicate relevant locations such as bus stops, train stations, taxi stands, or branch offices. Markers should not be distinguishable solely by color; instead, they should also feature a distinct symbol or letter. For example, a bus icon or the letter "B" could mark a bus stop, while a corresponding train icon could be used for train stations. This ensures the information remains understandable even if colors cannot be clearly distinguished.

Furthermore, markers must stand out clearly against the map background. Light corporate colors—such as light blue or light green—are often insufficient for this purpose; instead, colors with sufficiently high contrast should be used.

In my view, a high-contrast mode is essential. However, I am not certain which map services currently offer such a feature; I have not encountered it in Google Maps or OpenStreetMap so far. It is possible the feature exists, but I simply haven't found it yet.

If a map service supports high-contrast mode, that feature should certainly be used. If no such option exists, the provider should be contacted with a request to implement it. While there are other map providers besides Google Maps and OpenStreetMap, these two are the most well-known. Regardless of the provider, the goal should be to offer a high-contrast map display.

If a map includes a legend, that legend must also be designed for accessibility. Although such legends are relatively rare, they can be used, for instance, to indicate different categories of locations.

Color or shape should not be the only distinguishing features. A red symbol for a bank and a green symbol for a café alone are not enough. This information must also be conveyed textually or through clear symbols. This also corresponds to the WCAG requirements for the criterion of sensory characteristics. Color or shape should never be the only way to distinguish information.

Since WCAG 2.2, the requirement for the minimum size of interactive elements also applies. It also affects cards. Clickable elements such as markers or points of interest must be at least 24 × 24 pixels in size or have sufficient distance between them. The map should therefore be designed in such a way that this minimum size can be maintained and individual markers can be easily selected.

Alternative operation

Another key point is how to use the card. On desktop systems it must be fully usable with the keyboard. For example, users should be able to enlarge or reduce the map using the plus and minus buttons. It should be possible to move the map section using the arrow keys. This means that the map can be fully operated even without a mouse.

Equally important is a function that allows you to return to the starting point at any time. If you move a lot on the map or zoom out a lot, you can easily lose your orientation. A reset view button makes navigation much easier.

These requirements apply not only to desktop applications, but also to smartphones. Mobile websites and native apps must also enable accessible map controls. In addition to touch gestures, there should be easily accessible controls. This includes buttons for zooming in and out as well as controls for moving the map section. This is the only way the card can be used reliably regardless of the input method chosen.

These features are among the basic requirements for accessible interactive maps. Under no circumstances should they be missed.

There is another important point in connection with keyboard operation. All markers or points of interest must be accessible via keyboard. These elements often contain additional information, such as addresses, opening times or other information. This information must also be accessible to keyboard users.

Another important aspect is the ability to skip the map. This is particularly true for desktop applications and is particularly important for screen reader users. Some cards behave problematically with screen readers. Users can access the map, but receive announcements that are incomprehensible or difficult to understand. Sometimes it is even difficult to leave the map again. What exactly causes this probably depends on the technical integration. Since maps often have limited use for blind people, it should always be possible to simply skip them. No one should be forced to navigate complex map controls when the actual information is available through other means.

The markers should therefore be focusable. If a marker receives keyboard focus, the associated information should be displayed, for example, in a tooltip or similar element. It is crucial that all content can be accessed without a mouse.

Testing with screen readers

A particularly important point is testing with screen readers. This shows whether the technical integration of the card actually works. In my opinion, maps can only be accessed to a limited extent with screen readers. Completely barrier-free use is hardly possible. It is all the more important that users do not become “trapped” in the map.

The test should therefore check whether the card is recognized as such, whether it can be skipped over without any problems and whether the focus can then continue to move normally. Nobody should be forced to work their way through the map with numerous tab keys. These tests should be performed on both desktop websites and native apps.

Offering alternative Ways

Let's come to the last and perhaps most important point: the alternative to the card.

An accessible alternative is essential. Maps have limited accessibility for screen readers. Even if individual markers are accessible, the spatial arrangement of the information remains difficult to understand. There are also people for whom maps are fundamentally too complex or who have limited ability to understand graphical representations.

Therefore, an equivalent alternative should always be offered. In my opinion, a tab solution is best suited for this. One tab contains the map, the other contains the same information in an accessible form.

This alternative can be implemented in different ways. What is possible is a table with all locations, a simple list of points of interest or – if there are many entries – a search function. For example, users could enter their address and then receive all branches or stops in the area.

Such an alternative often already exists in local public transport. The classic timetable information provides the route in text form, while the map merely represents an additional visualization. In this case, the information is already available twice: once as text and once as a map. This is a good solution.

What is crucial is that the alternative is equivalent in content. It must provide the same essential information as the card.

p>Complete route planning does not necessarily have to be developed yourself. It is often sufficient to hand over the navigation to an established map service such as Google Maps, OpenStreetMap or Apple Maps. Many users use these services for actual navigation anyway. This allows the application to provide its information in an accessible manner, while navigation is handled by a specialized map service.

More on accessible components