1.8 Ensure that all outputs can be perceived by users with restricted or no vision

Rationale

"
At night I can see the writing but by day I find it impossible to use. I know there's something written there but I don't know exactly what it says.
" - partially sighted user

Information output is usually provided as text and presented visually. Any user who cannot see to read the text will not be able to perceive the information it contains. Not being able to see text well enough to read it is often due to a combination of poor vision, inadequate text quality and poor lighting. So by increasing the legibility of the text or the lighting, even users with some visual impairment will be able to read and understand it.

"
I hate scrolling displays. They're nice because they are dynamic and they get your attention but I can't actually read them because I can't focus on moving text.
" - partially sighted user

Movement reduces legibility and some users who can read quite well are nevertheless unable to read the same text if it is moving.

" Queuing systems are a problem. The Revenue one is good because it speaks out 'ticket number 42 to desk 7'. But in other places I have to listen out for the number of times the counter clicks forward and sometimes I lose count and miss my turn.
" - partially sighted user

Often the only way the user knows something has happened is by listening to incidental noises, such as the click of the counter in a ticketed queuing system, the sound of the printer in a ticket machine or the whir of the motor in a cash dispenser. Even users who are totally blind can gather information about the outputs by listening for these noises. Although these noises are incidental, similar sounds can be included intentionally, ranging from simple clicks and beeps to spoken alerts.

" A speaking ATM would be great, as long as the volume wasn't too loud, so there would be no problem with security.
" - partially sighted user

When information outputs are displayed visually as written text, non-sighted users will need to be able to hear it spoken, although care should be taken not to compromise the user's security.

Directions and Techniques

Text size, contrast and typeface

Ensure that characters are at least 4mm high. Light characters on a dark background is best for contrast, e.g. White or yellow on black or a dark colour. Avoid using pale colours. Avoid red on green or yellow on blue. Avoid patterned backgrounds for text. Avoid all caps and underlining. Use a typeface that has numerals with open shapes such as Tiresias.

Avoid using scrolling text or animation

Provide adequate lighting and take steps to reduce glare

Most text displays use CRTs, LEDs or backlit LCDs so they provide their own light source. They should have enough power to provide a clear contrast between the light and dark areas in all conditions. If this is not the case, the display will have to be adequately illuminated form an external source.

Anti-glare displays can help reduce the problem of reflected light which reduces text legibility. The physical design of the terminal casing can also help by blocking direct or reflected light from reaching the display. However, be aware that anything that obstructs light from reaching the display may also obstruct the user's view.

Add voice output

Add voice output to speak any information that is displayed visually. This can be achieved using either pre-recorded audio or speech synthesis. Speech synthesis, whilst more flexible, is often of much poorer quality and may be difficult to understand for some users and in noisy environments. If voice output is likely to be intrusive or if the information is of a sensitive personal nature, allow the audio to be turned off during a user session and provide a standard jack socket for connecting an earphone. Inserting a jack plug should switch off the output to the external loudspeakers.

Headphone sockets
If voice output is likely to be intrusive or to be of a personal nature, provide a standard headphone socket.

For all visual cues, provide corresponding audible cues

Supplement visual cues, such as flashing indicator lights, with simultaneous corresponding audible cues, such as clicks, beeps and spoken alerts.

Allow user-selectable settings

Applying the previous techniques should result in a terminal which suits all users. However, in some cases, what is best for one group of users is not necessarily best for all.

If this is the case, it may help if the user interface can be adapted by the user, or automatically for the user, to fit their individual capabilities. For example, users who are visually impaired could choose voice output and large type, whilst users with good vision may prefer to have more detail and no sound.

The choice could be made by the user selecting from a number of displayed options. Alternatively, information required for the terminal to switch automatically could be encoded on a user's smart card at their request.

Do not rely on colour for meaning

Whilst colour coding can be useful as an aid to recognition, it should not be relied on entirely, since over 8% of Irish males and some females have difficulty distinguishing between red and green (other forms of colour blindness are relatively uncommon).

Do not rely on colour for meaning
The buttons on this web page rely on the users ability to distinguish between red and green.

How you could check for this:

Self-test early prototypes

Designers can run simple sight tests themselves on an early prototype, by simulating various types of vision loss. Complete loss of sight can be simulated either by wearing a blindfold, turning off the lights or putting the terminal in a black bag. To simulate partial sight, a test user who normally wears glasses could take them off. It is also possible to buy low vision simulation glasses which simulate various types of visual impairments. In all cases, extreme care should be taken to avoid injury through loss of balance or collision with unseen objects. This may require that the test user remains seated or, if they have to move around, obstacles such as floor cabling are removed in advance. Although this type of ad hoc testing will not replace proper testing with real users, it will give some insight into what it is like to be operating with reduced vision.

Test with real users

During development, you should test the prototype in a realistic situation with real people who have various forms of visual impairment. In particular, you should include people who are recently impaired and have not yet developed enhanced perception or coping methods. This is the only way to find out if your audio equivalents can be understood by users well enough to provide the intended information.
About user testing