Writing text alternatives for maps

Who uses text alternatives?

People with disabilities

Text alternatives are important for people with certain disabilities. The most obvious group is those who are blind or have very little sight. When reading online, they may be using a:

• Screen reader: software that reads out text, including the text alternatives for images or graphics
• Braille reader: device that provides a Braille version of the text and text alternatives that can be read with the fingertips
• Screen magnifier: software that enlarges text and graphical elements. When a map is very detailed, the software may not show enough legible detail or the graphic may become too pixelated to be legible at high levels of magnification. A text alternative will be very important in these cases.

People with cognitive impairments who find it hard to understand maps may also benefit from a text alternative.

Other people may benefit

Text alternatives can be:

• Helpful for older people whose vision is not as sharp as it was when they were younger
• Handy for those who just "don't get maps"
• Useful for people with limited bandwidth, unreliable power connections, or both (as often happens to me in rural India where I spend a few months of each year)
• Read by search engines to index your non-text content.

For interactive maps, text alternatives will also help those who may not be confident using the interactive controls.

Why does someone who cannot see need to use a map?

People with vision impairments need maps for most of the reasons that sighted people need them. They may need to:

• Assess the likely cost of a taxi fare
• Work out public transport options
• Find a convenient place to meet a friend
• Know what facilities or landmarks are nearby
• Be able to ask directions and get an answer that makes sense.

How to write text alternatives for maps

To write a text alternative for a map you will need to consider the:

• Reason you are providing the map on your site
• Information the map provides to a sighted user.

Then, think about:

• What your users will be doing with the information
• How you can organise the information to satisfy those uses. What structure (sequencing, grouping, labelling) will work well?

How to include the text alternative

The Web Content Accessibility Guidelines 2.0 set out several options for including a text alternative for a map. It can be:

• A separate, linked page
• On the same page as the map
• An ALT attribute on the IMG element for the map. Most maps will require more information than you can provide with the ALT attribute.

Example 1: Simple location map

On the 'contact us' page on a business website, you may have a link to a Google map below your address. You have included it to help people find your office, whether they are driving or travelling by public transport.

On the same page, include a text version of information about driving from the city and nearby landmarks. Also include information about travelling by public transport if this is the key information that a sighted user would get from the map.

Example 2: Detailed features and facilities map

On the Royal Botanic Gardens website, the 'Garden maps' page links to several maps. The first is a visitors' map. It helps visitors find their way to various lawns, plant collections and facilities. It is quite detailed and needs a detailed text alternative.

For this example I worked with Sam Vukanovic, the Digital Media Officer from the Gardens, to make sure I had interpreted the map correctly. Andrew Arch from the World Wide Web Consortium offered some useful suggestions. And Pierre Fredericksen and Josh Crawford from Vision Australia provided their feedback.

Design considerations for the text alternative

My main focus was on helping people find features and facilities shown on the map. I considered adding information about walking around on the various paths because I felt the location tables were a bit 'dry'. However, there is another map that has walking routes and the text alternative for that map should provide this information. Likewise, I could have included information about nearby parking (other than the disabled parking shown on the map), but this is provided elsewhere on the site.

The order I used for each part of the information was deliberate. I started with a general orientation, and then listed transport, parking and entry points ahead of the main features of the Gardens. I think this is the way most people would use the map—at least on first use. It would be worth keeping an eye on user feedback and changing the order as needed.

I used alphabetical ordering within the tables to make it easier to look something up by name.

I divided the list of lawns, lakes and gardens into two tables to give a sense of features in the north and those in the south. Another option would be a 3-column table with the third column giving the general location (north, central, south). This may make it easier to look up a feature, but makes it a little more work to get an overview of what is in the north versus south. Again, this should be monitored and changes made based on users' feedback.

References to the Gardens with a capital 'G', and to gates as 'Gate A' comply with the Gardens' style guide. I have used full names for some features that have abbreviated names on the graphical map.

Versions of the Melbourne map, Royal Botanic Gardens

Note: these are now links to pages on the Internet Archive, since they're no longer available on the Botanic Gardens website.

• Graphical version (GIF, 376KB)
• Text version