Guidelines for Application Software Accessibility - Printable Version

Technology introduction

these guidelines cover application software running under any operating system or runtime environment.

If the product or service combines application software with other technologies, then also refer to the guidelines for those other technologies. For example, if the application is hosted on a public kiosk, you should also follow the public access terminals accessibility guidelines.

Guidelines introduction

These guidelines cover application software running under any operating system or runtime environment.

Priority 1

Following priority 1 will ensure that the application can be used by most people with impaired mobility, vision, hearing, cognition and language understanding, using their assistive technologies.

1.1 Ensure that users have access to the operating system accessibility tools, without affecting application functionality

Most operating systems include accessibility tools to help users with impairments carry out the basic functions. These may include the following (although the names may differ from one system to another):

• Sticky keys - enables the user to generate combination key presses, such as ctrl+alt+f, by pressing the keys one at a time.
• Toggle keys - causes audible and visible alerts to be generated when the caps lock, num lock or scroll lock keys are pressed.
• Sound sentry - ensures that system sounds (beeps) are accompanied by a visible alert, such as a screen flash.
• Repeat keys - enables the user to adjust the rate at which keys repeat when held down.
• Slow keys - enables the user to adjust the length of time keys must be held down before the key press is accepted.
• Bounce keys or filter keys - prevents the keyboard from accepting quick consecutive presses of the same key.
• Mouse keys - enables the user to move the mouse pointer using the arrow keys.
• Screen reader - reads aloud the screen contents in a synthetic voice.
• Screen magnifier - magnifies the area of the screen around the focus point and displays it in a separate window.
• On-screen keyboard - a software keyboard, displayed on the screen, which emulates the hardware keyboard.

If these tools are provided by the operating system, users should be able to switch them on and off in the normal way. Using them should not block access to any of the application's functionality.

Similar guidelines are:

• 1.3 Adhere to all user-selected system settings for input and output
• 1.4 Adhere to the standard keyboard access methods

Rationale

Many users cannot operate their computer at all without using accessibility features like sticky keys that are provided with the operating system. For example, a person who has limited use of only one hand may be physically unable to hold down a modifier key, such as CTRL, and stretch the distance required to press a letter key at the same time. With sticky keys switched on, they can do this, because it eliminates the need to press several keys simultaneously. If an application interferes with sticky keys in any way, some functions may become unusable.

Directions and techniques

Avoid using the accessibility tool enabling actions for application functions

Accessibility tools are often switched on and off by carrying out a specific keyboard action of sequence of actions. For example, on many operating systems, pressing the shift key 5 times turns on sticky keys. In Windows, holding down the right shift key for 8 seconds turns on filter keys. And on the Macintosh, pressing command-shift-clear enables mousekeys.
information on windows accessibility tools.
information on mac os system 7, 8 & 9 accessibility tools.
information on mac os x accessibility tools.
information on unix/linux accessx accessibility tools.

How you could check for this:

Try switching each of the available accessibility tools on and off, using the keyboard, while the application is running

If you can verify that each tool always works after its keyboard enabling action has been performed, and that it stops working when its disabling action is performed, then you can be sure that the application does not interfere with access to the tools.

Verify that the application functionality is unaffected by use of the accessibility tools

The best way to do this is to arrange for the application to be tested by someone who normally uses the operating system accessibility tools. If it is difficult to find such a person, developers can try using each tool themselves to perform a range of application functions.

1.2 Ensure compatibility with assistive technologies

Users with impairments often use assistive technologies to enable them to provide inputs and perceive outputs. These include special keyboards, alternative pointing devices, screen readers and screen magnifiers.

Applications should be able to detect input from assistive technologies and generate outputs in a way that assistive technologies can detect.

Rationale

If an application manages input and output in a way that is not compatible with assistive technologies, some users may not be able to perceive the application objects or act on them. They will then be unable to use the application.

Directions and techniques

Use the standard system inputs

Assistive input technologies, such as special keyboards and pointing devices, use the standard system input mechanisms. If an application bypasses these mechanisms, for example by taking input direct from the keyboard rather than from the input buffer, it may not be able to detect input from the assistive technology.

Use the standard system outputs

Assistive output technologies, such as screen readers, monitor the use of the standard operating system drawing routines to determine what is displayed on the screen. This includes routines for displaying or erasing user interface components, text and graphics. If an application bypasses these routines, for example by drawing or writing text directly to the screen, the assistive technology may not be able to detect the output.

Use standard system user interface components, such as menus, buttons and dialogs

Standard user interface components provided by the operating system or java foundation classes (JFC) expose their state without requiring additional work from the application.

For custom user interface elements, use APIs that support assistive technology
custom user interface elements should be exposed to assistive technologies through a suitable application programming interface. This should enable assistive technologies to do the following:

• Find out which user interface element is at a particular location
• Find out the identity and state of a user interface element, including its type, handle, availability, content and value
• Receive notifications when the state of a user interface element changes, for example, when a control becomes disabled or when a text string changes
• Carry out actions that affect a user interface element, for example, click a button or select a text box

applications running on Microsoft windows can use Microsoft active accessibility for this purpose.
java applications can use the Java accessibility api.

Use logical event handlers

Use logical event handlers, such as onselect, rather than device event handlers, such as onmouseup. This enables the application to respond to events generated by any suitable device.

Use the system cursors and pointers, or keep them tied to the focus

Assistive technologies used by people who are visually impaired need to track the position of the system cursors and pointers. For example, screen magnifiers enlarge the portion of the screen around the mouse pointer, so they need to know where the mouse pointer is. Screen readers follow the system cursor or insertion bar during text entry, so they need to know where that is.

If an application uses its own method to indicate focus, such as special highlighting or moving an object around the screen, the position of the system pointers or cursors may not correspond to the application's focus point. The assistive technology will then be looking in the wrong place.

If alternative focus indicators are used, it is still possible to facilitate assistive technologies by moving the system cursors and pointers so that they are always in the same position as the focus indicator. This will work even if they are not visible.

If the focus covers a larger area, such as a table cell, it may be possible to define the system cursor to be the same size. This will help screen readers determine exactly what is within the focus area.

Do not require that the application takes up the whole screen

Some assistive technologies, such as screen magnifiers and on-screen keyboards, need to be permanently visible on the screen. They take up a portion of the screen, usually at the top or bottom, and the remainder of the screen can be used for application windows. If an application requires the whole screen and cannot be resized, the assistive technology will therefore obscure part of the application. The user will have to move the assistive technology in order to view that part.

Ensure that content makes sense when linearised

Screen readers traverse the screen and read out the elements in the order in which they are encountered. This converts the two dimensional screen layout into a linear sequence. Problems can arise if this linear sequence does not follow the logical ordering of the elements. This can render multi-column text unreadable and cause difficulties with forms.

For example, if two text blocks are presented side-by-side with only blank space separating them, a screen reader may interpret them as a single block and read the first line of the first column followed by the first line of the second column, before moving down to the second line. The two columns will then be mixed up and the text will make no sense at all to the user.

Another example is where a form requesting personal details consists of text entry boxes with a prompt for each. The logical order will be for the boxes to be read in the conventional order - first name, family name, address, etc. - and the appropriate prompt to be read before each input box. If the screen reader were to read out all the prompts before getting to the input boxes, it would be very difficult for the user to know which input box was related to which prompt. If the input boxes themselves appeared in a non-logical order, such as first name, address, then family name, it might also be difficult for the user.

How you could check for this:

Test with real users of assistive technologies

The only way to find out for sure whether an application is compatible with assistive technologies is for people to try using it with their assistive technologies. As far as possible, this should be done by people who routinely use the assistive technologies in their everyday life, rather than the application developers themselves. It would be possible for developers to test the application by obtaining an assistive technology, such as a screen reader, and using it themselves. However, this would be wasteful of resources and of questionable validity. For a non-impaired person to learn to use a screen reader effectively may take a few weeks of constant use. Unless that person relies on the screen reader completely, to the extent of unplugging their monitor, they may not end up using it in the same way that a non-sighted user would. This would make the test unrepresentative. A basic tenet of user testing is that representative users should carry out representative tasks in a representative situation. For accessibility, this means that users with impairments should be asked to use the application to carry out the tasks it is designed for, using their own assistive technology set up according to their own preferences.
about user testing

1.3 Adhere to all user-selected system settings for input and output

Most operating systems allow users to select their preferred settings for inputs and outputs. These include things like the keyboard repeat rate, mouse speed, double-click time, system fonts, colour scheme, cursor and pointer sizes and line widths. Applications should adhere to whatever preferences the user has selected. Similar guidelines are:

• 1.1 ensure that users have access to the operating system accessibility tools, without affecting application functionality
• 1.4 adhere to the standard keyboard access methods

Rationale

For some users, their preferred settings are the only settings that enable them to use the computer. For example, some users with visual impairments may be unable to read text unless it is in a large font and a particular colour scheme, such as yellow or white text on a black background. Users with poor motor control may be unable to point at and activate objects unless the mouse speed is reduced and the double-click time is increased. Most operating systems provide user-configurable settings for input and outputs. If the application does not apply these settings, some users may not be able to use it at all.

Directions and techniques

Use standard system user interface components, such as menus, buttons and dialogs

If an application uses standard user interface components provided by the operating system, the system settings, such as the font size on buttons, will be applied automatically.

Use system calls to determine required display characteristics for non-standard elements

The system settings for input and output may not be automatically applied to custom components such as buttons and panes defined by the application. In this case, the correct settings can be determined through system calls, such as the systemparametersinfo function in windows.

How you could check for this:

There are no specific test methods recommended for this guideline.

1.4 Adhere to the standard keyboard access methods

Keyboard access methods are keys or key combinations that can be used to access the functions and elements of the application, such as windows, commands, menus and controls, without using a pointing device. All operating systems have standard keyboard methods for navigating to and activating interface and application objects and standard keyboard shortcuts (accelerator key combinations) for directly activating common functions.

For example, in windows, repeatedly pressing tab moves the focus from one object to another, then pressing spacebar or enter activates the object that has focus. Pressing ctrl+c is a shortcut for cut and pressing ctrl+v is a shortcut for paste.

Users should be able to use all the standard keyboard navigation, activation and shortcuts defined for the operating system.

Similar guidelines are:

• 1.5 do not require use of a pointing device
• 1.10 ensure a logical tab order for controls, input fields and other objects
• 2.3 adhere to the operating system user interface guidelines

allow keyboard only access
many people use a keyboard but cannot use a pointing device.

Rationale

Some users can interact with a computer using a keyboard or keyboard emulator but cannot use a pointing device such as a mouse. To be able to learn and efficiently use an application, these users rely on the standard keyboard access methods that are provided by the operating system to be used by all applications. If these standard methods are not available, users will have to learn new methods which may take a long time and lead to frequent errors.

Directions and techniques

Refer to the official operating system user interface style guide

most operating systems and user interface environments have published standards for keyboard access.
Microsoft windows keyboard Guides.
macintosh human interface guidelines.
motif and cde 2.1 style guide.
kde user interface guidelines.
keyboard navigation for gtk+2.0 draft.
sun java look and feel design guidelines.

How you could check for this:

There are no specific test methods recommended for this guideline.

1.5 Do not require use of a pointing device

Users should be able to access all of the application functionality without controlling the mouse pointer. All functions should therefore be accessible from the keyboard but without using it to emulate a mouse.

An exception is granted for functions like freehand drawing, which require the user to describe an arbitrary path that cannot easily be expressed in any other way.Specifically, users should be able to use keys and key combinations to do all of the following:

• Navigate to and activate all menus and menu items
• Navigate between documents, windows, panes and modeless dialogs
• Navigate to and activate all controls in windows and dialogs
• Navigate to toolbars and activate any tools providing functions that are not also provided in menus
• Navigate within text and other document content and make selections
• Alter the properties of application objects

Similar guidelines are:

• 1.4 adhere to the standard keyboard access methods
• 1.10 ensure a logical tab order for controls, input fields and other objects

Rationale

Some users can interact with a computer using keys or switches but cannot use a pointing device such as a mouse. Users with limited motor control or hand tremors may be unable to control a pointing device accurately enough to target small objects. Some users may be impaired to the point that they can only operate a computer via a single two position switch.

If an application has functions that cannot be performed using the keyboard, some users will be unable to use those functions.

Directions and techniques

Allow tabbing to any object and activating any object from the keyboard

The primary method of accessing application objects via the keyboard is to use the tab key. Repeatedly pressing tab moves the focus from one object to another within a group. When the focus is on the desired object, some other key sequence can be used to activate it.

Tabbing between objects usually works within a group of objects, such as the buttons on a toolbar, so that when focus is on the last object in the group, pressing tab moves it back to the first object and the cycle begins again. Moving focus onto a different group can be done by pressing some other key sequence. For example, in windows, pressing the alt key switches focus between the menu bar, which can be tabbed through, and the application window. It is important to note that an object refers to a logical entity, such as a button. In some cases, things like toolbars may actually be constructed as a single image, with many active regions corresponding to the individual buttons on it. In this case, each individual button is a logical object, so it should be possible to tab within the image to each active region.Although this method is generally called "tabbing", it is not always the tab key that cycles focus within a group. Some applications are set up so that the tab key switches focus between different panes and the arrow keys are used to cycle through the contents of a pane. Windows explorer is one example.When focus is on an object, some key or key sequence can be used to activate it. Typically, the enter key or spacebar are used for this purpose. Some objects will require multiple activation methods because there may be many things that can be done to an object. For example, there may be one key sequence to launch it, another to open its properties for editing and still more for hiding or deleting it. Each operation should have a keyboard method.As far as possible, applications should follow the common standards for the operating system. These may include other conventions such as holding the shift key down to reverse the direction of tabbing.

As far as possible, allow direct keyboard access using shortcut keys

Although tabbing between objects is the primary method of keyboard access, and the easiest to learn, it can be slow. Shortcut key sequences should therefore be assigned to frequently used functions.

How you could check for this:

There are no specific test methods recommended for this guideline.

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

Users who are blind, partially sighted or colour blind should be able to perceive all of the information that is presented in text and graphics.

For any object on the screen, they should be able to identify what it is, what it is for and what state it is currently in. Objects include things like windows, buttons and other controls, text fields, application entities, rulers and status indicators. The type of an object, its purpose and its state may be indicated by visible attributes and associated labels. However, users with restricted vision must still be able to determine this information.

Where possible, visually displayed information should be delivered in a form that users who have partial vision or colour blindness can still see. Where this is not possible, and for users who are completely blind, an alternative form that they can perceive, possibly using assistive technology, should be made available and it should provide the same information.Similar guidelines are:

• 1.2 ensure compatibility with assistive technologies

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

1.7 Ensure that all information can be perceived by users with restricted or no hearing

Users who are deaf or hard of hearing should be able to perceive all of the outputs from the application.

Where possible, audible information should be delivered in a form that users who are hard of hearing can hear. Where this is not possible, and for users who are profoundly deaf, an alternative form that they can perceive should be made available and it should provide the same information.

Rationale

If audio output is used to present information, users who cannot hear well enough will not be able to understand the information being given. If audio output is used to alert the user to an incident, users who cannot hear the alert will not know the incident has occurred. Not being able to hear audio outputs or hear them well enough to understand them is often due to a combination of poor hearing, inadequate sound quality and background noise. So by increasing the sound quality and taking steps to reduce background noise, even users with some hearing impairment will be able to understand the information.

Directions and techniques

Provide adequate quality sound

Complex natural sounds, such as music and speech, should be recorded using professional equipment and adequate digital sampling rates. Speech output can be achieved using either pre-recorded audio or speech synthesis. If possible, use digitised pre-recorded speech which has been recorded in a professional studio and spoken by a trained announcer. Speech synthesis, whilst more flexible, is often of much poorer quality and may be difficult to understand for some users and in noisy environments.

For all audible cues, provide corresponding visual cues

Supplement audible alerts with simultaneous corresponding visual cues, such as flashing icons or window borders. Be careful not to conflICT with built-in operating system accessibility tools, such as sound sentry, which perform this function.

React to status of the "show audio" option if included in the operating system

Some operating systems provide a user-selectable "show audio" option (it may not have this name), which enables the user to request that all sounds should be accompanied by a visual event, including a caption for any spoken text. Application programs should react to this option by generating their own visual equivalents.

How you could check for this:

There are no specific test methods recommended for this guideline.

1.8 Do not cause the screen to flash at a frequency of above 2 hertz

Avoid all flickering or flashing with a frequency of more than twice per second. This includes flashing backgrounds or text, repeatedly turning graphics on and off or cycling between different images.

Rationale

Displays which flicker or flash can cause photosensitive epileptic seizures in susceptible individuals, particularly if the flash has a high intensity and is within the frequency range between 2 hz and 60 hz.

Directions and techniques

There are no specific techniques recommended for this guideline.

How you could check for this:

There are no specific test methods recommended for this guideline.

1.9 Use the simplest language possible for instructions, prompts and outputs and, where possible, supplement it with pictorial information or spoken language

The language that is used for things like operating instructions, button labels and displayed information should be clear, unambiguous and easily digested. This is what is meant by simple language and it does not mean that the text should be trivial or in child's language. It should not contain unnecessary jargon, colloquialisms, idiomatic expressions or convoluted grammar. Where possible, use explanatory icons, pictures or diagrams to aid understanding and provide for written text to be spoken for the benefit of users who have difficulty reading.

Rationale

Many people find it difficult to understand complicated written text. Overall, 25% of the irish population are "functionally illiterate", meaning that, while they can read to some degree, they would have difficulty reading a newspaper, filling in a form or following the instructions on a medicine bottle. Similarly, people whose first language is not english, such as first generation immigrants or foreign visitors, may have some reading ability but it may be low.

Literacy is also a problem for people who are deaf. A 1993 nrb survey found that 80% of deaf adults in Ireland had the reading age of an 8-9 year old. This is due to the difficulties of learning through sign language, which has a different grammar and structure to spoken or written language, or by lip reading.

There are various cognitive impairments, the best known being dyslexia, which also cause difficulty in reading complicated written text.

Directions and techniques

Keep it simple

The main technique is to keep it simple. Use everyday, jargon-free explanations. Avoid idiomatic expressions such as "on the one hand". Avoid long sentences by writing directly and concisely and break up information into small, easily digested blocks with headings. You will often find that phrases like "on the one hand" are mere padding and can be removed without changing the meaning of the sentence. It is best if all instructions and information are written by experienced professional technical writers.

Supplement written instructions with audio

people who cannot read are often perfectly able to understand the same text if it is spoken. 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 users to have the text read out by an assistive technology

As far as possible use "real text" rather than images of text. Assistive technologies, such as screen readers, can then read the text to the user.

Supplement written instructions with pictures

Icons and diagrams can convey large amounts of information in an easily and quickly digested form. This may be the only medium that can be understood by people who are deaf and have poor literacy.

Allow user-selectable settings

applying the previous techniques should result in text that can be understood by 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, some users may wish to choose spoken output, graphical buttons or fewer choices, whilst others may prefer to have only written text and more detail. The choice could be made by the user selecting from a number of displayed options.

How you could check for this:

Test with real users

try to ensure that all instructions and information are covered in the user tests which should include users who have low english literacy, preferably for a number of different reasons (education, nationality, hearing or cognitive impairment).
about user testing

1.10 Ensure a logical tab order for controls, input fields and other objects

In most operating systems, the tab key can be used to move the focus between user interface elements such as controls, text fields and application objects. The order in which the elements come into focus should reflect the logic of the interface.

for example, a simple form used to collect personal information about the user might contain text fields for title, given name, family name, and three lines of address, with a button to submit the details. The logical tab order would place the title and name fields together and place the three lines of address together, because that is how these items are grouped logically. The button would be last because that is the last thing the user does on the form. A tab order which interspersed the name fields with the address fields and had the button in the middle would not reflect the logic of how users think about the information and how they fill out and submit forms. Note that the logical ordering of tile, given name and family name varies from culture to culture, so there may not be a single, universally correct, tab order.Similar guidelines are:

• 1.4 adhere to the standard keyboard access methods
• 1.5 do not require use of a pointing device

Rationale

Tabbing is the primary method of accessing application objects via the keyboard. A logical tab order maximises efficiency by allowing keyboard users to predict roughly how many tabs will be needed to get to an object, where the tab will land next and what will be the most efficient direction to tab in. For blind users who cannot see the screen, it enables them to easily create a mental model of the interface layout. When filling in forms, a logical tab order means that the next piece of information that needs to be provided is always the obvious one.

Not providing a logical tab order reduces efficiency and can cause errors in forms where users type information into the wrong fields or reach the submit button without realising they have yet to fill in some fields.

Directions and techniques

There are no specific techniques recommended for this guideline.

How you could check for this:

There are no specific test methods recommended for this guideline.

1.11 Provide descriptions and instructions for all accessibility features

Users should be able to access information about all the accessibility features included in the application. This information should list and describe each feature and provide instructions for using it. Accessibility features will include keyboard equivalents for mouse functions and user-selectable preferences.

It is not necessary to describe the accessibility features provided by the operating system or other third party software.

Similar guidelines are:

• 1.12 provide accessible documentation, training and support materials

Rationale

The accessibility features built in to the application may not be apparent at first. Often users do not take advantage of useful functionality because they do not realise it is there. Once having discovered an accessibility feature, users may forget how to access it, so they will need an easy way of finding out.

Directions and techniques

List access keys and user customisation functions in a single, easily accessible place

Accessibility difficulties often make computer use laborious, so it is best to list all the accessibility features in one place, preferably a simple text file with a table of contents and a search facility.

How you could check for this:

Test with real users

run user tests in which users have to refer to the descriptions and instructions to learn to use accessibility features.
about user testing

1.12 Provide accessible documentation, training and support materials

Documentation, training materials and support materials such as online help, should be provided in accessible formats. Where possible, the standard format should be accessible to users who are mildly impaired. Where this is not possible, and for users who are severely impaired, an alternative format that does not require vision, hearing or dexterity should be made available and it should provide the same information.

Similar guidelines are:

• 1.11 provide descriptions and instructions for all accessibility features

Rationale

Documentation, training and support materials are an essential part of any but the simplest applications. Often, it is the lack of access to training and support that prevents users taking advantage of the application's functionality. People with impairments that prevent them from perceiving all of the information in the interface may have a greater need for training and support than other users.

Directions and techniques

Check the materials against the application software accessibility guidelines

Most of the criteria that documentation, training and support materials should adhere to are the expressed in these application software accessibility guidelines.

Provide online text-based materials

This is often the most accessible format. Any user who can access the application itself should be able to access material in this format.

If providing paper documentation, avoid light colours and use a "lie flat" binding

Light colours may not be reproduced well by photocopiers, which users with impaired vision may use to make a "large print" copy of the documentation. The binding should allow it to lie flat while it is open.

How you could check for this:

Test with real users

documentation, training and support materials are an essential part of the application and should be user tested in the same way. Run tests in which users have to use the training materials to learn to use the application and refer to the documentation and support materials during use to help them carry out tasks.
about user testing

Priority 2

Following priority 2 will make it easier to use and will include more people with cognitive impairments or multiple disabilities.

2.1 Allow sufficient response time to accommodate the slowest users

Users should be able to ensure that operations such as logging on or reacting to an alert are not timed out or interrupted by system prompts until even the slowest users have had sufficient time to complete the operation.

Rationale

Completing an operation in the application will require the user to carry out a number of separate activities. These may include reading and understanding instructions, choosing the appropriate action, recalling information and making the inputs. Each of these activities will take some time and different users will require different amounts of time, depending on their abilities and confidence.

Users who have poor reading skills or have difficulty understanding written text may have to read the instructions very carefully a few times before they can understand them fully.Having read the instructions, choosing the appropriate action will take longer for users who have an intellectual impairment.Recalling information such as pin numbers or personal details is more difficult for many older users or people who are tired or stressed.Making inputs by pressing buttons or typing on a keypad can take much longer for users who have physical difficulties.Some response delays may also be caused by the use of assistive technology used to read the screen.It can be very frustrating to be constantly prompted to complete a task and the stress that this can cause makes it even more difficult for the user. Ultimately, the worst thing is to be timed out after a lengthy process and asked to start again.

Directions and techniques

Allow up to 10 times the average response time in order to accommodate the slowest users

To accommodate the slowest users, a good rule of thumb is to allow up to 10 times the average response time for each individual activity - reading and understanding, choosing, recalling information and making inputs.

Use timeouts only where necessary and reminders only where helpful

It is easy to include timeouts and reminders in software without much thought having been put into whether they are required for security and whether they are actually helpful to users.

Allow user-selectable settings

applying the previous techniques should result in an application 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 need more time to read, think and act could choose longer timeouts and no reminders, whilst users who are quick may prefer to have shorter timeouts for security. The choice could be made by the user selecting from a number of displayed options.

How you could check for this:

Guidance on how to test whether this guideline has been met, at different stages during the development and release cycle.

gather time-to-task data during user tests or after a first release, it is possible to gather data from a broad range of users about how long they take over each activity - reading and understanding, choosing, recalling information and making inputs. This can then be used to produce more accurate rules determining how long to allow. However, this should only be done by trained statisticians and the amount of data required for statistically significant calculations will be quite large.
about user testing

2.2 Ensure that the user interface and task flow is similar across different functions

A uniform presentation and consistent interaction style should be used for all functions of the application. This includes the task flow, screen layouts, how outputs are displayed and how inputs are made.

Rationale

All users find it difficult when the presentation, interaction style or task flow varies. People with cognitive or learning disabilities find it particularly difficult. Consistency helps enormously by making procedures easier to understand and enabling users to transfer the skills learnt on one task to other tasks. If there is no consistency between tasks or, even worse, if there is no consistency over time for a given task, users will have to repeatedly relearn the procedure.

Consistency is also vitally important for users who have difficulty perceiving the instructions and controls. The consistent placement of interface elements from one screen or dialog to another makes it far easier for screen magnifier and screen reader users to find things. Memorising a routine sequence of actions is a major strategy employed by blind computer users. If the interface is inconsistent so that the task flow varies from function to function, they will be less able to use standard sequences of steps.

Directions and techniques

Define and follow a standard style

Consistency is achieved by defining a standard style and following it. This can outline standards for aspects such as colours, control sizes, positioning, task order and writing style for instructions and information. Standards should be written down in the form of a style guide and one or more members of the development team should be assigned to act in a quality assurance role, reviewing the design to ensure it adheres to the style guide.

It may be possible to enforce the standard automatically, by developers using templates or some kind of content management system.

How you could check for this:

Try to repeat a task by using a standard sequence of operations

While carrying out a task, write down the sequence of operations you perform, in terms of physical actions such as button presses. Try to repeat the task a number of times by following this sequence exactly, without looking at the displayed instructions. If the result is in any way different, then there is inconsistency.

2.3 Adhere to the operating system user interface guidelines

All operating systems have standard user interface guidelines defined by the authors. These describe how applications can achieve the correct "look and feel". Look and feel covers things like:

• Positioning and ordering of window and dialog box elements
• Shape, size and spacing of buttons, fields and checkboxes
• Use of standard components such as the file and edit menus and the save and save as commands

applications should follow these guidelines.Similar guidelines are:

• 1.4 adhere to the standard keyboard access methods

Rationale

Following user interface guidelines ensures that an application's look and feel has as much in common with other applications as possible. This makes it easier to learn and use, because users can rely on previous experience with other applications to help them activate functions and interpret outputs.

This is a major benefit all users. In particular, it greatly helps users who have cognitive impairments. It also greatly helps visually impaired users who find it easier to use an application if they can rely on rote learning of specific operations, rather than having to perceive everything.

If the application does not follow user interface standards, users will have to learn new methods which may take a long time and lead to frequent errors.

Directions and techniques

Refer to the official operating system user interface style guide

most operating systems and user interface environments have published look and feel guidelines.
Microsoft windows user interface guidelines
Macintosh human interface guidelines
Motif and cde 2.1 style guide
KDE user interface guidelines
GTK+/Gnome application development manual
Sun java look and feel design guidelines

Use the standard user interface toolkit

The easiest way to adhere to user interface guidelines is to use the standard user interface toolkit or widget set, rather than create custom interface components for the application.

How you could check for this:

There are no specific test methods recommended for this guideline.

2.4 Provide accessible packaging, installation and configuration tools

Where possible, package the installation media and printed materials in such a way that users who have limited strength or dexterity can open the package. Ensure that all installation and configuration software conforms to the application software accessibility guidelines.

Rationale

End users often have to unpack, install and configure their own software. Being unable to do this can be frustrating or even degrading and may mean that they have to wait a ling time before they can use it.

Directions and techniques

There are no specific techniques recommended for this guideline.

How you could check for this:

Test with real users

The only way to know for sure whether users with impairments can successfully unpack, install and configure the application, is to ask them to do it. Before beginning the tests, agree on what is the maximum reasonable time it should take to complete each task. Compare this with how long users actually take.
about user testing

2.5 Provide for users with multiple impairments

Users with multiple impairments, such as those who are both visually and hearing impaired, should still be able to use the application. Features that are provided to accommodate users with different impairments should therefore be supplementary rather than mutually exclusive. That is, using one should not prevent the user from using others. If possible, visually impaired users should be provided with facilities that do not require good hearing. And hearing impaired users should be provided with facilities that do not require good vision or reading ability.

Rationale

loss of vision, hearing and dexterity often occur together, particularly as the person gets older. For example, approximately 35% of people with a visual impairment also have a hearing impairment. A high proportion of people who are deaf also have low literacy. A 1993 nrb survey found that 80% of deaf adults in Ireland had the reading age of an 8-9 year old. This is due to the difficulties of learning through sign language, which has a different grammar and structure to spoken or written language, or by lip reading.

Directions and techniques

Make modes of use complementary

where alternative or enhanced input and output modes are provided, such as large text, graphical buttons, large buttons and audio output, ensure that users can use them together. For example, instead of providing a choice between one user interface with large text and large buttons and another with spoken text and an spoken prompts, allow the user to choose any combination of these helpful features. The choice could be made by the user selecting from a number of displayed options.

How you could check for this:

There are no specific test methods recommended for this guideline.