Navigating accessibility in two dimensions

We usually take for granted how efficiently maps convey information like proximity, spatial relations, distance, and geographical context in a compact visual manner across two dimensions. Attempting to translate that to a non-visual medium and navigate interactive elements linearly by keyboard quickly pulls back the curtain on that illusionary ease. In this two-part series, we first take a closer look at the challenges of displaying accessible map markers with the Google Maps API and then propose some solutions.

Separate but equal?

Alternative text content for visual media has been a principle of accessible web design for almost as long as visual media has existed on the web. The image alt attribute dates back to 1995 and the HTML 2.0 specification, and nowadays the very first success criterion of WCAG, the definitive guide to accessible web content, outlines how to provide a text alternative for non-text content.

Although the alt tag’s original purpose was for static images, the idea of fallback text persisted as browsers began to host more rich media experiences: gifs, audio and video clips, image maps (remember those?), Flash games, Flash websites, interactive SVG, and now Canvas and WebGL.

Up to a certain point, text fallbacks seem like the only common-sense solution. Audio needs a transcript, and video gets captions and audio descriptions to address lack of vision, hearing, or both. These alternatives address dimensions of the media that are, for now, impossible to replicate entirely outside the sense they target. Text fallbacks in these cases also allow content in audiovisual media to be searchable and translatable as well as accessible.

The waters begin to muddy once interactive non-text content gets introduced. Leaving aside the thankfully short-lived trend of embedding all content in Flash, there are still significant challenges in making something like a simple interactive line graph accessible to screen readers. Even if the controls and all data points are keyboard-accessible (and that’s a big if on today’s web), the overall trend of the data only gets surfaced visually.

Mapping the current state of accessibility

Currently, the most accessibility-conscious sites provide a manually written extended description using something like aria-describedby, or link away to an alternative experience like a table of data for that line graph. It’s hard to argue that this form of text alternative reaches the same level of equivalence as an audio transcript or video captions. A well-designed data visualization efficiently communicates a trend or relationship found in the data, whereas a table of the same data requires significantly more mental effort to reach the same understanding.

Long-form text descriptions are a brute-force to make up that difference and are the only technique for dealing with graphs and maps found in WCAG recommendations and third-party guidelines. A good description must get manually written and tailored to be effective, however. This description may not be an issue for a static visualization of a known data set but quickly becomes prohibitively labor-intensive or even impossible when interaction and user-generated data get thrown into the mix.

Maps: the challenge

Maps are only one subset of the discussion around accessible data visualization, but even geographic data alone is too varied and extensive a problem space to tackle at once. For context, this is an incomplete list of map-related accessibility concerns out of our scope:

• Chloropleths and other regional data overlays
• Clickable regions
• Street view
• Directions
• Directions that account for accessibility concerns (e.g., lack of curb cuts, accessible public transit)

The issue we’ll be exploring is mapping a collection of data points using the Google Maps API. It seems extremely specific, but starting here allows us to explore in depth some of the fundamental challenges involved in taking a map — a visual, two-dimensional interactive information display — and making it accessible to both keyboards and screen readers.

Another benefit of limiting the focus to the Google Maps API is that it is both ubiquitous and has poor accessibility out of the box. On the other hand, its flexibility and variety of features give developers much control over baking accessibility into custom maps and overlays. We focused on keyboard and screen reader access as those are the two most common modes of access that run into the most significant problems navigating maps and mapped data.

Describing the map itself

Here’s a fun game to play: open up Google Maps to a random location and zoom level, and try to describe the map to someone who can’t see your screen. Do this a few times with a different location and zoom each time, and see what patterns emerge in your description.

Faced with the map above, you probably end up with something like “map of western Washington, USA, centered on Seattle. Zoom in a few more stops, and it could be “map of Seattle, centered on the downtown area.” Both of these are deceptively simple: a description of where the map is centered, and the area covered.

Trying to construct the description gets a little more complicated: the level of specificity — neighborhood vs. city vs. region — used for both the map’s center and extent changes with its zoom. However, it’s not a one-to-one relationship. A map with the same size and zoom as above but centered on Worcester, MA would cover several states, and panning over to Zagreb, Croatia allows it to cover multiple countries. An intuitive map description is as dependent on context as it is on its area. No wonder the most common solution is to write something manually.

Thinking about data relationships

Since this whole post is about displaying data markers on top of a map, the geographic context isn’t the only visual information that needs a non-visual translation. Take a quick glance at the following map image and try to list everything you notice about the black markers without spending more than 30 seconds thinking about it:

• There are roughly 10-12 points on the map
• The points are mostly spread out, except for a cluster of five in the center-left
• There are two points nearby towards the center-bottom

There is more that could be said: for instance, nearly all the points are on arterial roads. However, the first thing you likely noticed about the markers was their rough count and spread. The number is easy to expose to assistive tech: mark them up as a list, and that happens automatically. That leaves their position relative to the map and relative to each other.

Navigating between markers

Related to the challenge of communicating the distribution of data points is the problem of navigating through them intuitively. Since a user may need to navigate by keyboard in conjunction with a screen or a screen reader, the order must make sense visually.

Top to bottom or left to right

The most straightforward possible ordering of the map markers would be to sort them by latitude or longitude. It makes sense on one level since we read from left to right (with the option to switch based on locale), but it ignores the importance of the map center. It also seems more intuitive to move from one point to another based on proximity rather than reading direction.

Start in the center and move outwards

Starting in the center seems more intuitive, but it introduces the problem of how to move outwards. There may be some perfectly natural path spiraling outward based on a combination of latitude, longitude, and proximity, but it is not at all obvious what it would be.

Use the arrow keys

One way to get around needing a linear path through points scattered across two dimensions is to make use of the arrow keys to move through both dimensions. This approach has the tangential benefit that only the active marker would need to be in the focus order, thus making it easier to to exit the map immediately. The difficulties are 1) it is not always obvious which marker is direct to the left/top/right/bottom of the current one, and 2) this way of navigating through the map would need to get communicated to the user.

Build ways to skip between map regions

Providing a way to skip directly to the map center, or the south-east is a way to cede greater control to the user. It also means that, should someone wish to interact with a specific marker, they would not need to tab through every marker before it. The issue with this solution is that it is not a solution: there still needs to be a logical way to move through markers within each of the regions.

Conclusion

Now that we’ve described many of the challenges around describing and interacting with a set of mapped data points, you should be all set to start thinking of ways around them. As you do, make sure you:

• Consider keyboard navigation for both sighted and non-sighted users
• Remember that not everyone is in the U.S.
• Explain any non-native keyboard interaction to the user
• Consider that screen readers use custom keyboard shortcuts

We’ll be back soon with our take on accessible Google Map markers!

Next steps