Image maps and location maps are a great way to manage complex information or to add a layer of interactivity. But with this tool comes complexity for the user. If the user can’t interact with your map or, worse, doesn’t know that the content exists, the map loses its purpose.
To achieve the best experience for all users, your maps must be easy to read, understand, and interact with.
Specific issues could include:
making maps keyboard accessible
avoiding keyboard traps
providing map content in alternative formats
using labels to enhance accessibility
making map content accessible when stylesheets are disabled
This OzWiki category outlines what to avoid, as well as best practice for presenting a location map visually and functionally so that all users will have the best experience. As image maps can involve using complex images with interactive hotspots, they have similar issues and some specific problems are included in this category.
Perhaps you need a comprehensive list of likely issues related to the use of interactive maps and image maps in web content – and how to address them. Or maybe you just want to ask a direct question and get a clear, expert response.
OzWiki tells you what you need to know in order to use interactive maps and image maps in an accessible way. The Interactive Maps section details 20 accessibility problems and how to address them, demonstrating compliance with 16 WCAG Level A success criteria, and 4 WCAG Level AA success criteria.
As a subscriber, you’ll also be able to request further or more detailed information relating to your specific situation.
See an example
Interactive map does not have an accessible alternative
All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed:
Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to WCAG 2.0 guideline 4.1 for additional requirements for controls and content that accepts user input.)
Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to WCAG 2.0 guideline 1.2 for additional requirements for media.)
Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.
OzWiki is an accessible resource that provides best known methods to achieve A & AA level design and interaction for web content in areas such as Audio, Video, Link, Captcha, Maps, Navigation and more. These outlined accessibility errors, examples and solutions help you become 508 compliant by demonstrating associated WCAG 2.0 success criteria and techniques.
Gain access to more detailed information on all OzWiki categories for only $39/month by purchasing a subscription today! You can cancel your subscription at any time.