The emergence of Web 2.0 technologies has created opportunities for the visualisation of much information on the web. For example a dashboard showing the current state of a business can summarise a great deal of information on a single page and highlight areas of interest or concern.

Unfortunately the way this information is presented may mean that it is difficult, or impossible, for people with various forms of disability to access it. A visual on a screen is of no use to someone who is blind. I will come back to how to present information in this situation; but I want to look at how to support other groups first, because good design can not only make visualisation accessible, but can also make the information more accessible.

The design principles underlying the WCAG standards apply equally to visualisation. I am going to look at various disabilities and see how they can be supported.

Colour Blindness
I will start with colour blindness because it is relatively common and because solutions are fairly easy to design-in if it is considered early. It also ensures that if the visual is displayed in monochrome or printed in black and white the information is still retained. The basic principle is that colour should not be the only distinguishing feature.

So for example, lines on a graph can be distinguished by colour but should also be distinguished by the type of line (dashed, dotted, thickened etc) or by the tick marks along the line (crosses, boxes, circles etc). Areas in a pie chart should be distinguished by a pattern as well as the colour. Furthermore the designer should consider how to use the power of Web 2.0 to improve the accessibility. In this case the slice of the pie could be highlighted when the legend is chosen and vice versa.

Magnification
Many people find the standard text size on the web difficult to read and find text sizing a very useful feature. Clicking the size up one or two notches makes it more comfortable and less tiring to read. With visualisation there are three interrelated types of sizing:

• Zoom in/out
• Text and icon sizing
• Level of detail in the display

Maps are a good example of how these interact. Zoom enables the visualisation of the whole of the United States or just a single block in New York. As we zoom in, the visualisation will add more detail going from just showing the States, the major highways and rivers down to showing the house numbers, street names and traffic direction. The size of the text, or symbols, will not change as we zoom in.

A user with vision impairment will need to be able to configure the text and symbol so that, for instance, the text is always 24 points rather than the typical 10 points. Alternatively, it may be better for the user to point at the text or icon and have the detail displayed in a separate pane with a suitable size, font and colour.

Excessive detail, such as thin lines for streets, will not be visible to a user with poor vision and will just make the map fuzzy. The user should be able to specify the level of detail. A simple way to do that would be to specify that the level of detail is the same as it would be for a standard user one or two zoom levels out.

Mouse-less access
WCAG says that all functions and information should be available without using a pointing device such as a mouse. This is essential for blind users (who cannot point) but is also required by some users with muscular-skeletal impairments such as RSI or missing upper limbs. These users control the computer by a limited number of short-cut keys or switches; pointing is very difficult with these input devices.

Visualisation technology needs to be built so that all its functions can be accessed without a pointing device. For example simple controls such as zoom-in must be accessible via menus and short-cut keys. Further, any object in the visualisation, for example a process box in a business flow diagram, should be accessible via alternative techniques. Possible techniques include:

• A separate pane with a list of the objects that can be chosen.
• A say-what-you-see function, which enables a user to speak or type the name of the object and for it to be highlighted.
• A tab function that jumps from one object to the next.

Screen-readers
Finally, let me discuss visualisation and users who are blind and depend on screen-reader technology. How can the information that has been visualised be supplied in a form that a screen-reader can process it?

Dashboards basically visualise tables of information so the screen-reader should be presented with well marked-up tables, any information that is highlighted in the visualisation (e.g. a traffic light that has gone red) should be available in a separate section that can easily be navigated to, for example by having a section with a header of ‘highlights’.

Diagrams, such as business flow diagrams, should provide lists of the objects in the diagram and for each one, on request, further details. The details should include the type, name, description, position and a list of links to other objects. With this type of information the user will be able to navigate around the diagram and develop a mental image of the diagram or more precisely an understanding of the concept the diagram attempts to portray.

Maps and other spatial representations are the most difficult to support. The question that needs to be answered is what information would a blind person want from such technology. My understanding is that this would include:

• How do I get from A to B?
• What is the nearest station, coffee shop, bank to B?
• What countries border C?
• Which towns does River R flow through?

All of this information needs to be provided in a structured text format that the screen-reader can navigate like a document.

Technology
Most of the functionality I have described above has to be provided by the visualisation technology rather than by the webmasters. I will be reviewing suppliers of visualisation software during the summer.