Michael Gaigg: Über UI/UX Design

25Mar3

Question: How can Internet Mapping Applications be made accessible?

Following I will identify areas that make web-based maps inaccessible as per WCAG 1.0 (please see section: 'Questions and Possible Research Areas').

Shout for Help

Question: How can Internet Mapping Applications be made accessible for users with disabilities?

If you are currently working on resolving any (or all) of these issues, know of somebody that is working on them or even know existing solutions, I would greatly appreciate if you pointed them out to me.

It is absolutely impossible to continue with our current approach to seek exceptions as a 'work-around'!

Background

It is important to note that I'm not talking about simple Google maps like driving directions or locate services that could be described through alternative, textual output.
Many times a map is the means to select, query, mix and eventually analyze data across multiple layers from multiple services. The input requires good vision and motor skills (mouse) and same applies to the output that is highly visual as well.
A simple example that illustrates this fact pretty well is shown in Figure 1, Drive Times from a specific location based on traffic grid.

ESRI Map, Drive Times

Figure 1: ESRI Map: Drive Times; produced using ArcGIS JavaScript API, http://mapapps.esri.com/serverdemos/siteselection/index.html

The Law

Section 508 as explained by Authority 29 U.S.C. 794d: “Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data that is comparable to the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.”
This law is extended and applicable to companies that develop applications for the agency, i.e. ESRI has to adhere to the Section 508 Standards.
The Section 508 Checkpoints were translated into Web Content Accessibility Guidelines which cover most of Section 508 and describe its implementation in terms of HTML & CSS.

Current ‘Solution’

So far, exceptions to this law have been granted for the specific case of online maps. It is believed to impose an ‘undue burden’ to the agency/contractor to make maps accessible. In many cases a 1-800 number was provided that would help the user to get the same information.

Questions and Possible Research Areas

Currently the following WCAG checkpoints are Level 1 (A) show-stoppers and need to be solved/researched/implemented:

Checkpoint 1: Provide equivalent alternatives to auditory and visual content

How to read a map when blind? E.g. redundant text for active regions/content.

Checkpoint 2: Don’t rely on color alone

Map application could provide different color schemes/black&white/shades of gray?!

Checkpoint 6: Ensure that pages featuring new technologies transform gracefully

How to provide a map (or alternative) that can be used when scripts are turned off?

Checkpoint 8: Ensure direct accessibility of embedded user interfaces

Do not write event-handlers that rely on mouse-coordinates (device-independence; see also Checkpoint 9)

Checkpoint 9: Design for device-independence

How to navigate a map without a mouse?

Checkpoint 12: Provide context and orientation information

How to describe the content of a map (especially after a change, e.g. query)?

You know of a solution?

Please get in touch with me if you know of solutions to these problems!

I hope that solutions for these problems can be found and maps become available to everyone. As always, not only users with disabilities will benefit from these efforts but also the applications themselves, e.g. better SEO (search engine optimization), alternative support for mobile user agents, assistance for elderly people, etc.

Similar Posts:

About Michael Gaigg

Michael Gaigg is a User Interface Expert at Esri. He is the team lead of the UI Engineering group in Professional Services and has been designing map applications for over 8 years.
Comments (3) Trackbacks (0)
  1. Thank you,

    very interesting article

  2. Ah, great! This cleared up some confusion I've heard.

  3. I know this is old, but I've recently started a pet project on making PDF maps Section 508 compliant. I had just about given up on the sort of maps you are working on, relocating my frustrations with 'simple' Subway Maps. Some of the issues you are talking about I too had to deal with and I came up with some solutions to it that might be more helpful to you. Please keep in mind that this is taken from the context of a Static Map, whereas yours is obviously more dynamic. But, I think the point here is that by starting simple we might be able to derive some more complex answers.

    Another caveat is that I haven't had much experience with GIS software (with the exception of MapPoint back in the early 00s). I'm sorry if this all comes across as rather rudimentary; I'm only trying to help.

    At the risk of becoming 'Captain Obvious", I would suggest placing some sort of boundary around what are you are going to work with in order to make something accessible. In other words, limit your map to a certain area and build only upon that area.

    From there, I would think about making lists for the streets, using the main streets as the root of those lists. This would allow you to tag coordinates in the [label] alt text a little easier to make them correspond with searches. Unfortunately, only after one massive list (and subsequent sub-lists) is generated, can we really begin to address the bulk of the issues of the Checkpoints.

    Structuring as lists allows for a bit more leeway in terms of directional components to screen readers. We can really make use of [label], [lbody], and [caption] references as well as alt tags for [LI] and [UL]. Having a visual aid (e.g. a Legend) for myself helped to differentiate the various list labels, for example, which I used to signify one type of subway stop or the other. Similarly, you could use list labels to point out block information and Caption tags to explain coordinates or intersections.

    I think this would solve some of Checkpoint 1, 2 & 8. I think identifying the function of the map would probably dictate how you solve Checkpoint 9 & 12. If an enduser is using the map to get from point A to point B, I assume that the search term she or he is using to find something will check the database for an acceptable match, and that query would return a value that is equal to coordinates that match up with those in the list mentioned above. Therefore, the information that would be returned would be generated from the list and you wouldn't need a mouse to use that. I suspect that some script would need to translate coordinates to a Left or Right turn and how many blocks.

    Which leads me to Checkpoint 6. I don't think there is a way to avoid using scripts, because the nature of all this requires the user to ask the server something and have some information retrieved to explain it back to the user.

    I think if you are able to make a more accessible map, it would be better than making a fully 508 or WCAG compliant map, understanding that maps are still considered too much of a burden. However, you'd probably be the first to figure this out, and you'd be able to attract that many more accessible users.

    I hope this was helpful.

    Jonathan Metz http://www.jonathanmetz.com


Leave a comment


No trackbacks yet.