1.7 Ensure that all outputs under the control of the device can be perceived by users with restricted or no vision

Rationale

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.

Take steps to reduce glare
Ensure that when the device is installed the screen is visible to those both seated and standing.

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

Often the only way the user knows something has happened is by listening to incidental noises, such as the whir of the motor in a card slot. 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.

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

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.

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.

Provide audible indication of phone and network status

It should be possible to tell the status of the telephone (on, off, ready, charging, dialling, etc.) without requiring vision. This can be done using either beeps or spoken announcements.

Consider text size, contrast and typeface

Ensure that characters are at least 4mm high but avoid using all upper case which is more difficult to read than mixed case. For good contrast, use light coloured characters on a dark background, e.g. White or yellow on matt black or a dark colour. Avoid using pale colours or patterned backgrounds for text. Also avoid red on green or yellow on blue since these combinations may cause problems for people who are colour blind. Use a typeface designed for display, such as Tiresias, which has numerals with open shapes which are easier to distinguish for people with low vision.

Avoid using scrolling text

Some visually impaired users find it difficult to focus on moving text.

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.

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 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.

Allow user-selectable settings

Applying the previous techniques should result in a device 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 (on telephones with digital displays), 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 telephone to switch automatically could be encoded on a user's smart card or SIM card at their request.

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 telephone 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