IMPORTANT: This article is being preserved for historical purposes. Current information and documentation about GNOME Accessibility can be found at: the GNOME Accessibility Project

Prev Next

User Interface Guidelines for Supporting Accessibility

When designing your application's GUI, there are a number of simple guidelines you should follow to ensure that it can be used by as wide an audience as possible, whether in conjunction with assistive technologies or not. Don't be fooled into thinking that this is just a case of "making your GUI usable by people with disabilities", though, and that you shouldn't bother if you know a disabled person is never going to use your application. Following these guidelines will improve the overall usability of your application for everyone who uses it— including you!

General

We all get frustrated if we can't find a feature in an application, or make a mistake from which it takes a couple of minutes to recover, if it's possible to recover at all. If you have some sort of disability, the chances are the effort and time penalties involved will be several times worse. Following a few basic guidelines can help prevent these sorts of situations for all users.

• Provide Undo for every action that changes the user's data or the application's settings. If possible, provide more than one level of undo and redo, and a history list to allow preview of what actions will be undone.
• Provide commands to restore default settings. If a particular setting could make the application completely unusable for an individual, e.g. by making the fonts very small, it would be useful to provide an option to restore the default settings outside the application itself. This could be done using a command line switch, for example.
• Help prevent users from doing the wrong thing. This is particularly important for actions that could be done by accident (e.g. mouse actions) or that cannot easily be undone (e.g. overwriting a file). Consider using confirmation dialogs or forcing the user to go into a particular mode to perform potentially destructive actions.
• Minimise users' memory load. For example, let the user view multiple documents at the same time, and ensure online help or other instructions can remain visible while they carry out the procedure being described. Allow them to copy any information that is displayed, and paste it anywhere that data can be entered.
• Don't make users insert disks. Depending on a user's particular disability, they may find it difficult to physically insert or change a disk, or they may find it hard to identify the correct disk in the first place. If your application is installed from CD-ROM, provide an option to copy all the files that will be required onto the user's hard drive.
• Don't place frequently used functions deep in a menu structure. Whether you're using a mouse, keyboard or some other input device, deeply-nested menu items are best avoided. As well as the cognitive burden of remembering where to find them, they are always more difficult and time-consuming to access.
• Don't lead users through unnecessary steps. For example, druids are useful for users who have trouble handling large numbers of options at one time, but other users may need to minimise the amount of time or keystrokes they use. Such users benefit from being able to skip unnecessary steps or go directly to the one they need. Consider providing a Finish button in druids that skips right to the end and assumes default reponses for the intermediate steps. If the druid has many steps, consider asking the user at the start if they want to run through all the steps, or just the most commonly-used ones.

Keyboard Navigation

A well-designed keyboard user interface plays a key role when you are designing accessible software. Blind users can navigate software more effectively using the keyboard, because using the mouse depends on visual feedback of the mouse pointer location. Also, mobility impairments can prevent a user from successfully navigating using the mouse, because of the fine motor control skills required.

It is therefore important to make all mouse actions available from the keyboard, and include keyboard access to all toolbars, menus, links and buttons. Every function your application provides should be available using the keyboard alone. Hide your mouse while you're testing your application if you have to!

Most functionality should be easy to make accessible by using keyboard mnemonics and accelerators, and the toolkit's built-in navigation features. However, operations that rely on drag-and-drop, for example, may require more thought.

• Provide efficient keyboard access to all application features. Some users may be unable to use a mouse, and many "power-users" prefer to use the keyboard anyway. Also, some specialised assistive technology input devices may simulate keyboard events rather than mouse events. Since typing is difficult or even painful for some users, it is important to provide a keyboard interface that minimises the number of keystrokes required for any given task.
• Use a logical keyboard navigation order. When navigating around a window with the Tab key, keyboard focus should move between controls in a predictable order. In Western locales, this is normally left to right and top to bottom.
• Ensure correct tab order for controls whose enabled state is dependent on checkbox, radio button or toggle button state. When such a button is selected, all its dependent controls should be enabled, and all the dependent controls of any other button in the group should be disabled. When the user selects a checkbox, radio button or toggle button that has dependent controls, do not automatically give focus to the first dependent control, but instead leave the focus on the button.

• Don't over-ride existing system-level accessibility features. For example, AccessX is an X server extension that has been supported since X11R6. The "MouseKeys" feature of this extension allows mouse movement and button clicks to be simulated using the keypad. Therefore you should not add features to your application that can only be accessed by pressing keys on the keypad, as users relying on the MouseKeys feature will not be able to use them.

• Provide more than one method to perform keyboard tasks where possible. Some users may find some keys and key combinations easier to use than others.
• Provide both keyboard and mouse access to functions where possible. Some users may only be able to use either the mouse or the keyboard, but not both.
• Don't assign awkward reaches to frequently performed keyboard operations. Some people may only be able to use one hand on the keyboard, so shortcuts that can be easily used with one hand are preferable for common operations. In any case, having to frequently perform long or difficult reaches on the keyboard can increase muscle strain for all users, increasing the risk of pain or injury.
• Don't require repetitive use of simultaneous keypresses. Some users are only able to press and hold one key at a time. Assistive technologies such as AccessX may allow users to press the keys sequentially rather than simultaneously, but this of course means the operation will take longer for them.
• Ensure that any text that can be selected with the mouse can also be selected with the keyboard. This is a convenience for all users, but especially for those for whom fine control of the mouse is difficult.
• Ensure that objects that can be resized or moved by drag and drop can also be resized or moved with the keyboard. For example, icons and windows on the desktop. Where precision sizing and placement is potentially important, e.g. shapes in a diagram, also consider providing a dialog into which you can type co-ordinates, or a means of snapping objects to a user-definable grid.
• Don't use general navigation functions to trigger operations. For example, do not use basic Tab keyboard navigation in a dialog to activate any actions associated with a control.
• Show keyboard-invoked menus, windows and tooltips near the object they relate to. In GNOME 2.0, users can call up popup menus with Shift-F10, and tooltips with Shift-F1. Do not completely hide or obscure the object to which the menu or tooltip refers, however.

Mouse Interaction

Remember that not everybody can use a mouse with equal dexterity, and that some users may have difficulty seeing or following the mouse pointer.

• Don't depend on input from mouse button 2 or button 3. As well as being physically more difficult to click, some pointing devices and many assistive technology devices only support button 1. Some assistive technologies may not emulate the mouse at all, but generate keyboard events instead.
• Allow all mouse operations to be cancelled. Pressing the Esc key should cancel any mouse operation in progress, such as dragging and dropping a file in a file manager, or drawing a shape in a drawing program.
• Provide visual feedback throughout a drag and drop operation. As the mouse passes over valid targets, highlight them and change the mouse pointer. Use the "no drop" mouse pointer when passing over invalid drop targets. See Mouse Interaction Examples.
• Don't warp the mouse pointer, or restrict mouse movement to part of the screen. This can interfere with assistive technologies, and is usually confusing even for users who don't rely on ATs.
• Don't make mouse targets too small. In general, mouse targets should be at least the size of the "hot area" around the resizable window border in the current window manager/theme-- bearing in mind that a user with impaired dexterity or vision may be using a window manager with larger areas than the default.

Mouse Interaction Examples

Figure 2. Example of "no-drop" pointer from CDE/Motif

Graphical Elements

Provide options to customise the presentation of all the important graphical elements in your application. This will make it easier for people with visual or cognitive impairments to use.

• Don't hard-code graphic attributes such as line, border or shadow thickness. These elements should ideally be read from the GTK or window manager theme. If this is not possible, provide options within your application to change them.
• Provide descriptive names for all interface components. The GAIL library provides default accessible descriptions for many GTK widgets, but you will still need to add your own in some cases, such as for widgets that use graphics instead of text (e.g. a well in a colour palette, or an icon without a label). Consider overriding the defaults with more helpful or application-specific descriptions where possible.
• Allow multi-colour graphical elements (e.g. toolbar icons) to be shown in monochrome only, if possible. These monochrome images should be shown in the system foreground and background colours, which the user will have chosen for themselves (by their choice of GTK theme) for maximum legibility.
• Make interactive GUI elements easily identifiable. For example, do not make the user hover the mouse over an object to determine whether it is clickable or not. Leave sufficient space between objects and clearly delineate object boundaries. Don't show GUI elements that look pretty but don't actually do anything, unless you also provide an option to switch them off.
• Provide an option to hide graphics that don't convey essential information. Graphical images can be distracting to users with some cognitive disorders. The icons on the GNOME foot menu, for example, can be switched off whilst still leaving the menus fully-functional.

Fonts and Text

Even to a user with normal vision, textual output provides the majority of the information and feedback in most applications. It is therefore critical to choose and position text carefully on the screen, and leave the choice of font and size to the user, to ensure that people with vision impaiments can also use your application effectively.

• Don't hard-code font styles and sizes. The user should be able to adjust all sizes and typefaces. If for some reason you cannot make this functionality available, never hardcode any font sizes smaller than 10 points.
• Provide options to turn off any graphical backdrops or "watermarks" behind text. Such images interfere with the contrast between the text and its background, which can cause difficulty for users with visual impairments.
• Label objects with names that make sense when taken out of context. Users relying on screenreaders or similar assistive technologies will not necessarily be able to immediately understand the relationship between a control and those surrounding it.
• Don't use the same label more than once in the same window. If you use the same label in different windows, it will help if it means the same thing in both windows. Also, don't use labels that are spelled differently but sound the same, e.g. "Read" and "Red", as this could be confusing for users relying on screenreaders.
• Position labels consistently throughout your application. This normally means immediately below large icons, immediately to the right of small icons, and immediately above or to the left of other controls. See Fonts and Text Examples.
• When you use static text to label a control, end the label with a colon. For example, Username: to label a text field into which the user should type their username. This helps identify it as a control's label rather than an independent item of text.
• When you use static text to label a control, ensure that the label immediately precedes that control in the Tab order. This will ensure that the mnemonic (underlined character) you assign to the label will move focus to or activate the correct control when pressed.
• Provide alternatives to WYSIWYG. Some users may need to print text in a small font but edit in a larger screen font, for example. Possible alternatives include displaying all text in the same font and size (both of which are chosen by the user); a "wrap-to-window" option that allows you to read all the text in a window without scrolling horizontally; a single column view that shows the window's contents in a single column even if they will be printed in multiple columns; and a text-only view, where graphics are shown as placeholders or text descriptions.

Fonts and Text Examples

Figure 3. Correct label placement for various GUI elements

Colour and Contrast

Poor choice of colours on the screen can cause problems for users with colour blindness (for whom hue is important) or low-vision (for whom brightness/contrast is important). Generally, you should allow the user to customise the colours in any part of your application that conveys important information.

Users with visual impairments may require a high level of contrast between the background and text colours. Often a black background and white text is used to prevent the background from "bleeding" over. These settings are critical for users with visual impairments.

• Don't hard-code application colors. Some users need to use particular combinations of colours and levels of contrast to be able to read the screen comfortably. Therefore all the main colours you use in your GNOME application should be taken from the GTK theme, so the user can set the colours for all their applications to something legible just by changing the theme. If for some reason you do need to use colours that are not available in the theme, ensure they are customisable within the application itself.
• Don't use colour as the only means to distinguish items of information. All such information should be provided by at least one other method, such as shape, position or textual description. See Colour and Contrast Examples.
• Support all the high contrast GNOME themes (when we have some!). Ensure that when one of these themes is selected, all the text in your application appears in the high contrast foreground and background colours specified by the theme.
• Ensure your application is not dependent on a particular high contrast theme. Test it with different high contrast themes to ensure your application respects the settings.

Colour and Contrast Examples

Example 13. Example illustrating redundant use of colour

Magnification

Many users, even those not visually impaired, benefit from magnification of text and graphics. However, without magnification, a visually impaired user may not be able to access and use the program at all.

• Provide the ability for the user to magnify the work area.
• Provide options in the application to scale the work area. Users need to have an option to magnify the work area 150% to 400% or more. Test the application to confirm the object you are vierwing is not affected by changing the magnification settings.

Audio

People who have difficulty hearing, as well as those who work with the sound on their computers turned off, will be disadvantaged if your application relies on sound to convey information. In general, make sure that the user is able to have any audible information conveyed in other ways.

• Don't assume that a user will hear audio information. This applies as much to users with broken soundcards as it does to those with hearing impairments!
• Don't use audio as the only means of conveying information. Give the user the option to have all audio information provided in a visual way as well. This includes providing closed captioning or transcripts for any important spoken sound clips.
• Allow users to configure frequency and volume of all warning beeps and other sounds. This includes being able to turn off sound altogether.

Animation

Used sparingly, animation can be useful for drawing attention to important information in your application— and it can look cool, too. However, it can be problematic for some users, so make sure they can turn it off.

• Don't use flashing or blinking elements having a frequency greater than 2 Hz and lower than 55 Hz. This includes text as well as any graphical objects. Anything in this frequency range may cause particular problems for users susceptible to visually-induced seizures. Note that there is no "safe" frequency, though. If flashing is essential, you should use the system's cursor blink frequency (which should itself be customisable), or allow users to configure the frequency themselves.
• Don't flash or blink large areas of the screen. Small areas are less likely to trigger seizures in those susceptible to them.
• Make all animations optional. The animated information should be available in at least one non-animated format, at the user's request.

Keyboard Focus

Showing the keyboard focus position clearly at all times is important for users those with vision impairments, as well as "power-users" who prefer to use the keyboard rather than the mouse. There should never be any confusion as to which control on the desktop has focus at any given time. You ought to be able to leave your computer with the focus on any widget in your application, then go off and phone your girlfriend or walk the dog until you've forgotten which widget you left it on. When you return, you should be able to tell straight away exactly which widget it was.

A visual focus indicator is an audio representation of the cursor position relative to the other objects on the desktop. This allows the user to move among objects interactively as the focus changes. The visual focus must be programatically exposed to assistive technologies. Note that in most cases, this is handled automatically by the ATK, without requiring you to do any additional work. However, you will need to be aware of this requirement when writing your own custom widgets, for example.

• Start focus at the most commonly used control. If no control in a window is deemed to be the "most" useful, start the focus at the first control in the window when that window is opened. Focus should not be started on the OK or Cancel buttons of a dialog even if they are the most commonly used controls, as they can always be activated immediately by pressing Enter or Escape.

• Show current input focus clearly at all times. Remember that in controls that include a scrolling element, it is not always sufficient to highlight just the selected element inside that scrolling area, as it may not be visible. See Keyboard Focus Examples.
• Show input focus only in the active window. Hide all primary visual focus indicators in all windows that do not have the focus and activation. If a single window has separate panes, only one pane should have the focus indicator, and focus indicators should be hidden in all other panes. If it's important to continue showing which item in an unfocused list is selected, for example, use a secondary focus indicator. See Keyboard Focus Examples.
• Provide appropriate feedback when the user attempts to navigate past the end of a group of related objects. When navigating a list, for example, stopping with audio feedback is usually preferable to moving the focus back to the first object in the list. Otherwise, users who are blind or have low vision may not realise they have returned to the beginning. In the case of a text search in a document, a dialog may pop up to indicate that the end of the document has been reached, and ask if you want to resume the search at the start of the document.
• Play the system default audio or visual warning signal when the user presses an inappropriate key, or when a navigation key fails to move the focus. For example, when the focus is on the first character in a text field and the user presses left arrow key, or the user tries to perform multiple selection in a single selection dialog. (Note that users with hearing difficulties should be able to configure a system-wide visual equivalent to the default warning sound.)

Keyboard Focus Examples

Example 14. Example illustrating need to show focus clearly

Example 15. Example illustrating use of secondary focus

Timing

Interfaces in which things appear, disappear or happen according to some hard-coded time limit are often a hindrance to accessibility. Some users may read, type or react very slowly in comparison to others. If information they require is hidden before they are finished with it, or obscured by other information popping up which they didn't explicitly request, then your application will become very frustrating or even impossible to use.

• Don't hardcode timeouts or other time-based features. Examples include automatic scrolling when dragging an object towards the edge of a window, holding down a scrollbar button, or automatically expanding a tree node when an object is dragged over it and held for a short time. These should either be customisable in the application, the GNOME control center, or at worst, manually editable from the command line via a configuration file or GConf entry.
• Don't briefly show or hide information based on the movement of the mouse pointer. (Exception: system-provided features such as tooltips, which the user can configure on a system-wide level). If you must provide such features, make them optional so users can turn them off when a screen-review utility is installed.

Documentation

People with disabilities cannot use the application effectively if they do not have access to the required manuals and help files. Of particular importance is keyboard navigation, since this is the only way many users can navigate the application.

• Provide all documentation in an accessible format. ASCII text and HTML are both excellent formats for assistive technologies.
• Provide alternative text descriptions for all graphics in the documentation.
• Document all your application's accessibility features. Keyboard navigation and shortcuts are particularly important to document. Include an accessibility section in your documentation, where information on all the accessibility features can be found.

Home Prev Next