1.6 Ensure that all information can be perceived by users with restricted or no vision

Rationale

Information output is usually presented visually using text and graphical objects. Any user who cannot see well enough to read the text or make out the graphics will not be able to perceive the information it contains. Not being able to see well enough is often due to a combination of poor vision, inadequate text and graphic quality and poor use of colour. By increasing the legibility, even users with some visual impairment will be able to read and understand it.

Information is often expressed using colour, such as green for on and red for off. However, users who are colour blind may not see the difference and may therefore miss the information. Movement also reduces legibility. Some users who can read text quite well are nevertheless unable to read the same text if it is moving. Users who are blind can operate a computer by using an assistive technology called a screen reader. This is a piece of software that reads out the contents of the screen. This includes the names of windows, menus, buttons and other controls, the labels and contents of input fields and any text that is written in windows or dialogs. The user can navigate around the screen using the keyboard, read the text and select or activate objects. However, for an application to be usable, the screen reader must be able to perceive the text and the objects and tell the user what they are, their purpose and their current state or contents. If this information is unavailable to the screen reader, it is unavailable to the user. Depending on how the application defines its text and objects, this information may be unavailable and the information or functionality will be hidden from users who are blind.

Directions and Techniques

Ensure that the application is compatible with assistive technologies used by people who are visually impaired.

Refer to guideline 1.2 "Ensure compatibility with assistive technologies".

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.

Use logical names for user interface elements

Since screen readers rely on description rather than appearance, the name of each user interface element should adequately describe its purpose, even if the name is not visible on screen.

Associate labels with objects programatically.

If labels are not associated programmatically, screen readers will use proximity to determine the label for a control or object. Proximity is not an accurate way to determine object labels.

Provide text equivalents of images

Provide text descriptions of all images, for example, by using tool tip text. Avoid the use of unlabeled inline images embedded in text, such as icon screenshots in help text. When an image represents a program element, the information conveyed by the image must also be available in the text. If image maps with "hot spots" are used as buttons or toolbars, ensure that each hot spot has its own label.

Avoid duplicate names

Avoid having multiple objects with the same name in the same window or dialog if they do not perform the same function. Although differentiating information may be provided by contextual cues, such as positioning or adjacent text, screen reader users find it difficult and time consuming to locate this information and distinguish the objects from one another.

Avoid pop-up text boxes that disappear when the mouse pointer is moved

Pop-up text boxes are often used to provide context-sensitive help for user interface objects. These can be programmed to disappear when the mouse pointer is moved so the user does not have to click a close button. However, some assistive technologies, such as screen readers and reading assistants, move the mouse pointer along as they read the text or allow the user to point at individual words. The first movement causes the pop-up to disappear, so the user is unable to read the text. If these types of pop-up is used, there should be a way to lock them in place.

Consider the size of objects

To be readable to a wide audience, text characters should be at least 4mm high on the screen. The actual size they appear depends to some extent on the pixel density of the display. It also depends on whether the size can be controlled by the user. Text that is part of standard operating system user interface components, such as menu titles, can usually be resized by the user using operating system utilities. Text that is created by the application should also be resizable. Similarly, images such as icons should be large enough for most users to see or be resizable.

Resizable onscreen text
Many partially sighted users enlarged system fonts to aid legibility.

Ensure good contrast

For text, use strong colours that have a high contrast with the background colour. Avoid using pale colours or patterned backgrounds. Users differ in the colour combinations they find easiest to read. Many find that the best combination is light coloured characters on a dark background, e.g. White or yellow on matt black or a dark colour. Others prefer dark text on a light background, particularly black on white. It is best to provide a choice of colour schemes. Avoid red on green or yellow on blue since these combinations may cause problems for people who are colour blind. Also ensure high contrast between adjacent areas within icons and other images.

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 alone to convey meaning
The buttons on this web page rely on the users ability to distinguish between red and green.

Use a clear typeface on plain backgrounds

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 placing text on patterned backgrounds, since this reduces legibility.

Avoid using scrolling text or animation

Some visually impaired users are unable to focus on moving objects.

To achieve a custom look and feel, use standard components with the style set to "owner draw"

Many user interface toolkits allow standard components, such as buttons and drop down menus, to be given a customised look and feel by setting their style to "owner draw". This enables designers to apply their own visual appearance and highlighting behaviour, whilst ensuring that screen readers identify them as standard controls.

Allow user-selectable settings

Applying the previous techniques should result in a display which can be seen by a wide range of visually impaired 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 might prefer large yellow text on a black background and large icons, whilst users with good vision may prefer to have black on light grey with more detail.

High contrast onscreen text
Many partially sighted users customise the look and feel of their user interface to suit their particular impairment.

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