1.6 Ensure that users with restricted or no vision can use all functions of the device

Rationale

Control labels, prompts and delivered information are often provided as text but presented visually. Any user who cannot see to read the text will not be able to perceive the information it contains. The controls themselves have first to be perceived by the user before they can be operated. Again, this often relies on sight, so that people with restricted sight may be unable to use the telephone.

Directions and Techniques

Consider developing an audio menu

If the telephone interface relies on visible correlations between changing prompts and unlabelled buttons, as on many mobile phone interfaces, users may still not be able to identify which button is associated with each prompt. In this case, it may be best to develop a separate audio menu which prompts the user to press a number on the keypad for each choice. This can be done along the lines of Interactive Voice Response (IVR) systems which ask the user to "press 1 for this option, press 2 for that option" etc. 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.

Allow voice input

Voice recognition software can be used to enable users to choose functions by speaking the name and dial numbers by speaking the number.

Consider label text, colour and contrast

For label text, 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.

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

Add tactile indicators to buttons and keys

It is standard practice to put a single raised dot on the 5 key to help users orientate their fingers on the keypad by touch. It is also possible to emboss Braille on keys and buttons, although this is not as widely effective as it may seem, since less than 2% of visually impaired people can read Braille. Also, Braille has less value in outdoor situations during cold weather, because tactual sensitivity is dramatically reduced at lower temperatures.

Key and button design
Make buttons large and tactilely discernable.

Follow standard layouts for keypads

Visually impaired users rely on telephone keypads following the standard layout for numerals, # and * keys.

Raise or recess buttons and keys

Raise or recess the buttons and keys by at least 2mm over the surrounding area.

Provide tactile and audio feedback

Provide tactile and audio feedback to indicate the operation of controls. Tactile indication can be provided by requiring a gradual increase in the force to activate a control, followed by a sharp decrease as it is activated. Audio feedback can be given using a beep or click. For multiposition controls, feedback should be used to indicate the current position or status.

Raise the edges of input slots

Design a raised ridge around input slots such as those used for entering a card or plugging in a headphone jack. This will make them easier to locate by touch.

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, 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 device 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 device 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.
About user testing