Tips for making user interfaces accessible

Below is a series of tips for making applications compatible with accessibility programs, such as the Accessibility interface provided by Windows.

Use groups instead of labels.
If you use a Label to title a group of related widgets, remove the label and replace their parent composite with a Group whose text is the same as the title Label.
 
Avoid intermediate composites.
Accessibility tools will read as far up the parent hierarchy of a widget with focus as possible. Be sure there are no widgets without text anywhere in the tree.
 
Use read-only texts instead of labels.
A Text can be accessed using the keyboard and should be used if you want the information in a label to be accessible to keyboard navigation. Note that a label beside a text will be treated as a title and so if you have a title/value pair, it is only required that you make the value widget a Text.
 
Read and understand the IBM checklist.
IBM provides a useful checklist for good accessibility at http://www.ibm.com/able/guidelines/software/accesssoftware.html
 
Assign mnemonics to all menus and menu items.
Ensure they are unique within a given menu. If a menu is dynamically composed from multiple plugins, it may be better to not assign mnemonics since conflicts cannot be avoided in general (e.g. the File > New list, or Window > Show View list)
 
Assign mnemonics to all labels of controls in dialogs / preference pages / property pages (e.g. buttons, check-boxes, radio buttons, etc)
Ensure they are unique within the dialog. Be careful to avoid collisions with the default buttons (e.g. Restore &Defaults, &Apply in preference pages; &Next, &Back, &Finish in wizards). Do not assign mnemonics to OK and Cancel buttons. If you make OK the default button of the shell, and Cancel is equivalent to closing the shell, then Enter and Esc map to these by default. Generally doing something with Esc or Enter is a bad idea.
 
Ensure that controls that do not have labels are preceded by a label.
If a control does not have its own label (e.g. a text field), use a preceding label ending with ':' and assign a mnemonic to it. Screen readers like JAWS will read this label when the control has focus (see Window > Preferences > General)
 
Avoid extra free-standing labels.
You cannot navigate to free-standing labels with the keyboard and screen readers like JAWS skip these since they do not take focus
 
Do not assign mnemonics to controls in the main window.
Do not put mnemonics on controls in the main window (other than main menus and main menu items), even if it looks like a dialog (e.g. the form editors in org.eclipse.ui.forms) as these will usually conflict with menu mnemonics
 
Assign shortcut keys for frequently used functions (and only frequently used functions).
There are currently only two ways to hook shortcut keys in SWT: Consult the table of Eclipse SDK shortcut keys, available within Eclipse from the General > Keys preference page, to avoid collision.
 
Avoid Alt+{key}, Ctrl+Alt+{key} and Ctrl+Space+{key} combinations.
Try to save navigation context.
For example, in Window > Preferences, we now remember which page you had selected last. This avoids having to navigate through the list each time
 
Assign a specific person on the team to be responsible for accessibility on your project.
Everything that is important needs an advocate. Make sure that everyone on the team knows that good accessibility is crucial, and is willing to give the person their full cooperation.
 
Test for accessibility.
Have your team hold an occasional "unplug your mouse day" where they try to use the product using keyboard only. If you are developing on Window, get a copy of JAWSTM and ensure that your UI is usable with it