A More Accessible Map

As companies like Google and Yahoo! have simplified the process of placing information on a map by offering web services/APIs, the popularity and abundance of mapping applications on the web has increased dramatically. While these maps have had a positive effect on most users, what does it mean for people with accessibility needs?

Illustration:

Share This:

Job Board

Most online mapping applications do not address issues of web accessibility. For a visually impaired web user, these highly visual maps are essentially useless.

Is there a way to display text-based data on a map, keeping it accessible, useful and visually attractive? Yes: using an accessible CSS-based map in which the underlying map data is separated from the visual layout.

A different starting point

So what if, instead of starting from a map graphic and adding data to points located across the image, we start with the data itself and create a map based on the data?

First, let’s pick some data that has a geographic component so it can be placed on a map. For example, let’s use the 10 most populated cities in the world. Displayed as plain text, the list might look like this:

Tokyo, Japan – 28,025,000 people

Mexico City, Mexico – 18,131,000 people

Mumbai, India – 18,042,000 people

Sao Paulo, Brazil – 17,110,000 people

New York City, USA - 16,626,000 people

Shanghai, China – 14,173,000 people

Lagos, Nigeria – 13,488,000 people

Los Angeles, USA - 13,129,000 people

Calcutta, India – 12,900,000 people

Buenos Aires, Argentina – 12,431,000 people

Note: The data above is intended only as an example and may not be entirely accurate.

Not bad, but it would be nice to add some descriptive text to each of the cities to describe a little more about them. So, an example for just one city might be:

Shanghai, China

Shanghai, China is situated on the banks of the Yangtze River and has a population of 14,173,000, making it the sixth most populated city.

Organizing the data

Now that we’ve added some descriptive information to the city, let’s think about how to organize that data in HTML. A definition list (dl) would be a good way to organize this information because a dl has both definition term (dt) and definition description (dd) child elements. This means we can have the city’s name as a dt and the city description as a dd. Let’s see how that might look:

<dl>
<dt><a href="http://en.wikipedia.org/wiki/Shanghai%2C_China"
class="location" id="shanghai">Shanghai, China</a></dt>
<dd>Shanghai, China is situated on the banks of the Yangtze
River and has a population of 14,173,000, making it the
sixth most populated city.</dd>
...

Note that the anchor link within the dt was given a class and unique id. The id allows us to refer to each city individually, so we can locate it on the map. We’ll come back to this a little later.

Adding some style

So where are we now? We’ve created an accessible text-based list of items and their definitions. The data is what we want to convey to the user, regardless of whether they see it on a map or just as text, so we are in good shape. Now that we have the information organized, let’s make a point map out of it.

In a point map, there are three main items that are visually displayed: the map, the point(s) on the map, and data to display when the user clicks on or hovers over a point. We can very easily translate those visual items to the text-based dl we just created:

Map image = dl

Map point(s) = dt > a

Map point popup data = dd

The first step in making dl into a map is to add the background map image with a style. We will give the dl a class of “map” so that only those dls in a document get styled this way (in our example, as a world map).

The next step is to add a style for the dts that will allow the anchors within to be made into points on the map:

dl.map dt {
display: inline;
}

Next, we need to deal with the dd items which will be the data displayed when a point on the map is hovered over. We do not want the dd to display until the a within its associated dt is hovered, so by default we need to hide the dds. Since screen readers will ignore an HTML element with a style of display: none, we need to hide the data by positioning it far away from the browser’s view. The style for the dd will make the element look like a tooltip window:

Each of the dts contains an a which, by default, takes a user to the Wikipedia article corresponding to the city; this link is what will trigger the tooltip to display the dd. The link will be displayed as a point and the link text will be invisible, so again we need to move the text out of the browser’s view. Each point will also have a different location, but we’ll take care of that in the next step. The base style for the anchor links looks like this:

Finally, we need to add styles specific to each point on the map. These points are represented by the anchor links inside each of the dts. The placement of each point will be accomplished by assigning top and left values (since we already positioned them all absolutely in the above code snippet):

We’ve just created a basic map, so let’s look at where we are with our first example. This example places the points on the map, but does not display any information when a point is hovered over.

Display the data as a tooltip

Now that we have a map with points positioned, we need to display data when the points are hovered over. To display a tooltip we are going to have to use some JavaScript.

The JavaScript to show and hide the dd “tooltip” does so by modifying the style of the dd associated with the current a being hovered. A JavaScript function named showTooltip() places the dd back into the visible area of the browser by modifying its top and left style values, based on the location of the associated a point.

It would be very easy for us to use inline event handlers like onmouseover and onmouseout to accomplish this, but that wouldn’t be very unobtrusive. We want like our script to remain independent of our map and our markup. To do that we can have the JavaScript dynamically assign events to the anchor elements.

But before we dig into the JavaScript, let’s pause for a moment to talk about JavaScript objects. The JavaScript used in this technique makes use of object literal notation, so learning the basics of this will help you understand how it all works. Here is a basic example of an object literal:

One of the benefits of using objects in JavaScript is that we can use methods and properties in a more sensible manner. For example, with the above code we can call a method like person.talk() or get a property like person.name. Objects also allow us to reuse method and property names without causing conflict. For instance, if we were to add an animal object to the file above, it could also have an walk method (animal.walk()) without conflicting with the person.walk() method.

The script used to assign the events in this technique is a little more complicated, but here is a shortened skeleton of what this example script looks like:

Now let’s dig a bit deeper into some of the methods. For the sake of brevity we will not cover every method, but we will tackle the key ones.

The init() method is our constructor. This means the method is what we call to initialize our mapMaker object. It sets up the map by adding events to each of the anchor links inside the dts, making the tooltips possible. Let’s look at the init method:

The init method first collects all of the dl elements in the document by using document.getElementsByTagName( ‘dl’ ) and then loops through each, looking for one with a class of “map”. When it finds one, it collects its dt elements and loops through them, assigning event handlers (using the addEvt() method) to the anchor tag within. The events we’ve accounted for include mouseover (which calls the showTooltip() method) and mouseout (which calls the hideTooltip() method) and mirrors the same actions for the focus and blur events, respectively, to make the tooltip available for keyboard users.

Now let’s take a closer look at a portion of the showTooltip() method; this method displays the tooltip dd when a map point (dl.map > dt > a) is hovered. To display the correct tooltip, the function must know which dd is associated with each anchor. From the currently hovered anchor tag, this, we can move to its parent dt tag (this.parentNode) then to that dt’s dd (this.parentNode.nextSibling) which is the tooltip we want to display:

In the script above the dd tooltip style is changed to bring the element back into the visible area of the map, but the script also takes into account the size of the map and positions the tooltip so it does not go outside the background map image boundaries.

The last detail we need to worry about is running the script when the webpage has loaded. Sounds easy just call window.onload = mapMaker.init() right? Well you could do that, but it doesn’t allow other scripts to run on page load and it would be really nice to trigger this script to run after the page has loaded but before all of the images have downloaded. Thankfully, Dean Edwards has done the work for us on this one and you can check out his write-up of the technique for more information.

We have now reviewed the major parts of this map example’s JavaScript, but did not cover every single function in the script. The functions for adding events get fairly complicated and are outside the scope of this article; however, you can view the entire script here.

Now that we have added some JavaScript functionality let’s look at where we are with this second map example. We now have a visually pleasing map that provides more detail when the user hovers over a city. Of course, because this map is created from text-based data, the data displayed as a map can be read by a screen reader and convey the same meaning.

What about CSS on and JavaScript off?

We need to address users who have JavaScript turned off but use a browser with good CSS support. We want these users to get the lo-fi, but useable text version of the map, because without JavaScript enabled they won’t be able to see the tooltips.

To enable the tooltips and the map style, the JavaScript init() method can be tweaked to turn the map “on.” If the map is not “on,” it will simply display as text only. As we have given our map dl a class of “map,” we’ll need to add a second class: “on.” We’ll also need ot update our style sheet, adding .on to each style rule like this:

The above style will only affect dls that have are class-ified as both “map” and “on” (<dl class=“map on”>) and will not affect any dls with only a class of “map.” You can see this in action in our third example.

Getting fancy

Now that we have a functional map, why don’t we add some images to the tooltip? This next example map shows images inside the tooltip. Or, maybe you would like to have links inside the tooltip. To do this, we need the tooltip to be “sticky” and not hide when the point is moused off. Here is an example of a “sticky” tooltip map (the JavaScript functions have oviously changed slightly to make the tooltip stick). Finally, this technique also allows for us to place multiple maps on a single page, so we have lots of options.

Where in the world?

Now back to those wonderful APIs. What if you want to use one place points on this world map by latitude and longitude?

Server side scripting examples of how to dynamically place points on the map are beyond the scope of this article, but here is some pseudo code to convert latitude and longitude points to pixels for the world map image used in our example:

If you are considering using server side scripting to dynamically place points on a map, you might also consider having the background image of the map be set by JavaScript. This would allow a dynamic page to assign different background map images to the dl based on the area or zoom level you would like to display.

A quick review

Let’s review what we have done:

Started with a text-based list that has geographic components

Turned that text list into an HTML definition list

Styled the dl to look like a map

Styled the dt elements into points located around the map using CSS

Styled the dd elements to look like a tooltips, but moved them out of view

Used JavaScript to dynamically assign mouse and keyboard events to the map points

Enabled the dd “tooltips” to be styled back into view when the map points are hovered

Where to go from here?

The example of a more accessible map presented here is just that, a more accessible map. It does not claim to be the best way, just a different way to approach the problem of creating accessible geographic-type content without having to create multiple pages in different formats. This example will not address all types of accessibility needs, nor be an ideal solution to all types of web based maps or GIS applications; however, a text-based webpage is always a great starting point for addressing accessibility concerns.

Also in Issue № 215

Compared to other commonly used mapping methods, this technique starts with the data and builds a map around it. Text content is separated from the map layout. When content can be separated from layout the content is generally more accessible. This means that an alternative accessible version may not need to be created.

What we have built in this article is just the start of what might be done on a map. These same concepts could be used to place shapes, or even a drill down map to display detailed data for more specific areas or locations. The important thing to remember is to start with the text-based information you want to convey. First make the data readable and useful as text, and then make it into a map.

About the Author

Seth Duffey has been creating websites since 1995. He is the webmaster for the City of Davis, California enjoys creating web-based mapping applications, photography and learning daily from the multitudes of smart(er) web designers and programmers out there.

50 Reader Comments

More from ALA

Columns

The number of predictions that algorithms can make about us from even minimal data is shocking. Although we’re offered privacy settings that let us control who of our friends sees what, all our information and behavior tends to be fair game for behind-the-scenes tracking. We simply don’t know everything that’s being done with our data currently, and what companies might be able—and willing—to do with it in the future. Laura Kalbag believes it’s time to locate the exits.

Displays that are more tiny than our lowest-size breakpoints require a more condensed range of type sizes. If you don't already have in place a typographic system that can absorb the demands of this new context (watches, wearables, digital sticky notes, whatever), now might be the time to consider it. Matt Griffin was ready for anything because his site was simple and built to be future friendly.

March 19, 2015

From the Blog

It's all about us this week at ALA. From steps to sleep to social activities, we're counting every kind of personal data you can think of. But what's all that data add up to? How could we look at it—and ourselves—differently? In this week's On Our Radar, we ask ourselves—and our self—the tough questions.

That old monitor you've got lying around? Time to put it to work. Susan Robertson reminds us of how important it is to test our designs on older screens and ensure the things we build work well for everyone.

The future is here, for better or for worse—and this week, the ALA staff has been thinking about what that means: for our code (the impending arrival of HTTP/2), our content (publishing on Medium), and the cost of constant noise.

This week, the ALA staff is thinking about color accessibility, the process of building a vocabulary, the current state of web typography, and the lessons we can learn from skater culture. In other words: it's all about inclusion.