Web Access Centre

GIS and accessibility - Article - Web Access Centre

Summary: A look at the accessibility issues associated with putting GIS data on the Web, and practical advice on how these issues can be addressed.

Introduction
Key considerations
Key requirements
Different types of data
Providing information in alternative formats
Tackling accessibility: two examples
WAI and See it Right compliance
GIS and accessibility: download in alternative formats
Other articles

Web access centre - design and management resources

Introduction

At present, it is impossible to make graphic presentations of some types of Geographic Information Systems (GIS) data directly accessible to those using text, speech or braille formats to access their PC and the Web. Some types of data simply can't be made directly accessible with the technologies currently available. Various research projects are investigating alternative methods of accessing information, for example the use of variable sound to convey information, or the use of "virtual reality" technologies to enable information to be explored using a range of senses including touch. But practical implementations of these methods and technologies are some way off.

There are, however, interim accessibility solutions that can be implemented for many types of GIS data. These solutions require that the data is presented in an alternative, text-based format as well as graphically. The most suitable format for accessing and displaying the information will obviously depend on the nature of the information being presented. Relatively simple data might be presented as a table or series of tables in addition to the map presentation. More complex data might have to be summarised, and key elements of the data presented in tabular form.

Key considerations

When deciding what alternative presentations to provide in addition to geographic data, the following questions should be kept in mind:

Why are people likely to be using the system?
What kind of information are they likely to be looking for?

The answers to these questions will help to determine which kind of alternative functionality will be best suited to the data in question.

Key requirements

Provide users with different ways of interrogating the data.
As far as possible, ensure that users are not limited to particular hardware or software requirements (e.g. ensure that keyboard users are not excluded).
Provide users with different ways of being presented with the data.

Different types of data

There are essentially three types of data involved in GIS:

Individual features

Location details and other information for specific features. For example:

"Where's my nearest...?"
Job centres, council offices, hotels, etc.

Typical accessibility problems encountered with this type of data:

Data presented only in visual, graphic format (e.g. symbols on a map).
Use of colour to differentiate between different data elements.
Map controls not keyboard accessible.
Information about individual features displayed dynamically in response to moving the mouse cursor around the map display.

Databases of information

Discrete data items that can be queried based on location information. For example:

Who are my councillors?
What ward do I live in?

Typical accessibility problems encountered with this type of data:

In fact, this type of data is often presented in a reasonably accessible format. Although it incorporates elements of geographic mapping, the resulting information is usually textual in nature and presented in that format. Care does need to be taken, however, to ensure that the problems listed under "Individual features" above are not created when planning how to present this type of information.

Continuous / variable / statistical data

Data which shows variations, trends, patterns, etc, when viewed as an overlay on a map of a geographic area. For example:

Land usage
Population density
Average household income
Air pollution levels

Typical accessibility problems encountered with this type of data:

Data presented only in visual, graphic format (e.g. overlaid on a map).
Use of colour to differentiate between different data elements.
Map controls not keyboard accessible.
Ability to manipulate, interact with and interrogate the data only possible via the use of a mouse and a graphical interface.

Providing information in alternative formats

Depending on the type of data involved, a range of approaches are possible. Here are some suggested methods for providing alternative, text-based presentations of different types of GIS data:

Individual features

Provide a simple list of all features.
Provide a simple list of features by category (selected by the user). For example, a list of all job centres within the geographic area covered.
Provide a simple list of features by category and distance from a specified location (the category and location selected by the user). For example, a list of all hotels and restaurants within 5 miles of a given address or postcode.

Databases of information

Provide a simple list of all data (e.g. all councillors listed alphabetically and/or by ward).
Provide a simple list of data by category (e.g. all councillors for a selected ward or a specific address or postcode).
Provide a simple answer to a specific question (e.g. the name of the ward for a specific address or postcode).

Continuous / variable / statistical data

Provide a written summary of the data for a specific area (e.g. a description of the population density within a local authority area).
Provide a simple data table of the information (e.g. population density figures by ward).
Provide a data table of information extracted using criteria specified by the user (e.g. all wards with average household incomes over a specified value).

Tackling accessibility: two examples

1. A system showing population density within a local authority area.

This might be shown using gradations of colour overlaid on a map of the local authority area, with the user able to zoom in and out and pan the display around the area covered by the data.

We would want the graphic system to be operable using a keyboard as well as a mouse (or other pointing device).

A useful feature would be for the user to be able to select the colour or colours being used to display the data on the map.

In addition to the map presentation, there are some alternative ways for the population density data to be presented for those who are unable to use or access the mapped data:

By entering a postcode or Ordnance Survey grid reference, the user could obtain a reading of the population density for that location.
A brief textual summary of the data could be provided, describing the population density around the local authority area, and a table could be provided, listing the towns, villages and/or named areas within the local authority area along with the population density for that location.

Ideally, both of these options should be made available.

2. A system showing key features within an area, e.g. hotels, restaurants and leisure facilities within a town.

With this kind of data, we usually see a map overlaid with symbols showing the feature locations. Sometimes the symbols are clickable, resulting in information about that feature being displayed. The system may also allow the user to zoom in and out and pan the visible area around the map.

Again, we would expect the system to provide keyboard controls as well as mouse control. This might involve controls for cycling through the feature symbols currently displayed on the map, with a visible indication of the currently highlighted symbol, which can then activated (e.g. by pressing ENTER) to display the information relating to that feature.

There are a couple of alternative ways in which the same information could be provided for those who can't access it via the map system.

In the same way that the "store finder" functions on some shop websites, a search function could be provided where the user can request details of all features, or all features of a specific type (e.g. hotels) within a specified range of a postcode. The textual information could then be displayed on a search results page, starting with the feature nearest to the postcode location and working outwards.
If the number of features in the information database is relatively small, it might be feasible to offer the user the option of listing all features of a specified type, e.g. all hotels listed in alphabetical order.

And again, if both of these options can be provided (where appropriate), that will make the system more flexible and easier for a greater number of people to use.

WAI and See it Right compliance

Because there is currently no way of making some GIS data directly accessible to people using some assistive technologies (primarily those using screen reader software), the focus for anyone assessing a site containing GIS data should be on the following:

General accessibility issues, such as ALT text for Java Applets, and device independence.
The provision of one or more appropriate and suitably accessible alternatives for those who can't use or access the GIS data directly.

WAI Single-A requirements

For a site to achieve WAI Single-A standard, any GIS data systems included in the site should comply with the following WAI checkpoints:

WAI 1.1: Provide a text equivalent for every non-text element.
If Flash or Java Applets are used to present the GIS data, ALT text and a brief informative text alternative should be provided. This should be in addition to any alternative presentations which have been made available.
WAI 2.1: Ensure that all information conveyed with colour is also available without colour.
As far as technically possible, the GIS data should not rely solely on colour to convey information (e.g. to distinguish between two different types of data). If possible, users should be able to select patterns and/or text labels as well as colours to enable them to distinguish between different data elements.
Note, though, that the simple use of gradations of a single colour does not count as "use of colour to convey information" in this context, since these gradations will still be visible even where the colour itself can't be perceived.
WAI 6.2: Ensure that equivalents for dynamic content are updated when the dynamic content changes.
It is essential that the accessible alternatives provided function in such a way that if the GIS data is updated the alternative formats also show the updated information.
WAI 6.3: Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
It might be possible to make some instances of GIS data compliant with the initial requirement in this checkpoint. In most cases, however, the fallback requirement of providing an accessible alternative will have to be implemented.
WAI 11.4: If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.
This is the important checkpoint. Since it is not currently possible to make the GIS system directly accessible to some users, it is essential that some kind of alternative is provided.

WAI Double-A requirements

For a site to achieve WAI Double-A standard, any GIS systems included in the site should comply with the Single-A requirements listed above, and also with the following WAI Double-A checkpoints:

WAI 2.2: Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen.
The system should use good, contrasting colours for its data display, and/or the user should be able to select the colours to be used.
WAI 7.2: Until user agents allow users to control blinking, avoid causing content to blink.
If any aspect of the GIS system includes an option to have items blink under specific circumstances, this should be turned off by default.
WAI 7.4: Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages.
For "pages", think "GIS display". If an option is provided within the GIS system for the display to be updated automatically at a set interval, this should be turned off by default, and the user should be able to control the feature.

Potential problem checkpoints

Given current technology, it is likely that it will be impossible to comply with the following checkpoints.

WAI 6.4: For scripts and applets, ensure that event handlers are input device-independent.
WAI 9.2: Ensure that any element that has its own interface can be operated in a device-independent manner.
WAI 8.1: Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies.

Claiming Double-A compliance

Currently, it is necessary to fall back on Single-A checkpoint 11.4 and provide an accessible alternative. It will be necessary to note this in any accessibility standard compliance statements.

Since it is currently not technically possible to make GIS data systems directly compatible with some assistive technologies, our view is that a site should not be disqualified from claiming Double-A compliance purely because of the presence of GIS data, as long as suitable alternatives such as the ones described in the first part of this document are provided. It is also clear that this is the view of the e-Government Unit with regard to local authority compliance with UK government requirements for local authority websites.

However, once GIS data systems are available which are compatible with assistive technologies, and assistive technologies exist which can access such systems, it will be necessary to implement such a system in order to truthfully claim that a site is Double-A compliant.

See it Right logo requirements

In order for a website to qualify to display the See it Right logo, the current requirement is that any GIS data on the site should comply with all of the WAI Single-A requirements listed above, plus the WAI Double-A checkpoints 2.2, 7.2 and 7.4, also listed above. And of course, in complying with Single-A checkpoint 11.4, a suitable accessible alternative presentation of the GIS data must be provided.

Donna Smillie
Senior Web Accessibility Consultant
RNIB

September 2005

GIS and accessibility: download in alternative formats

Download the full paper and the presentation slides in alternative formats: