Tips for making user interfaces accessible
Below is a series of tips for making something usable to the IAccessibility interface provided by Windows.
1) Use Groups instead of Labels
If you use a Label to title a group of related widgets remove the label and replace thier parent composite with a Group whose text is the same as the title Label.
2) Avoid intermediate Composites.
IAccessibility tools will read as far up the parent hierarchy of a widget with focus as there are widgets to read. Be sure there are no widgets without text anywhere in the tree.
3) 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. Please note that a label beside a text will be treated as a title and so if you have a title:value pair you wish to show it is only required that you make the value widget a Text.
4) Read and understand the IBM checklist. http://www-3.ibm.com/able/accesssoftware.html
5) 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)
6) Assign mnemonics to all labels of controls in dialogs / preference pages / property pages (e.g. buttons, checkboxes, 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.
7) If a control does not have its own label (e.g. a text field), use a preceeding label ending with ':' and assign a mnemonic to it. Screen readers like JAWS will read this label when the control has focus (e.g. see Window > Preferences > Workbench)
8) Avoid extra freestanding labels as you cannot navigate to them with the keyboard and screen readers like JAWS skip these since they don't take focus
9) Do not assign 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 WSAD) as these will usually conflict with menu mnemonics
10) Assign shortcut keys for frequently used functions (and -only- frequently used functions).
There are currently only two ways to hook shortcut keys in SWT:
- by setting an accelerator on a menu item in the main menubar (they are ignored in context menus)- JFace actions have support for this
- by hooking a key listener on a particular control (e.g. in the implementation of a view or editor)
Consult the table of Eclipse SDK shortcut keys (available off of eclipse.org -> Projects -> Eclipse Project -> Platform -> UI -> Development Resources -> Accessibility) to avoid collision.
12) Avoid Alt+{key} combinations since they may conflict with menu mnemonics
13) Avoid Ctrl+Alt+{key} combinations since they often conflict with entering special characters on international keyboards (alt Gr = Ctrl+Alt)
14) Avoid Ctrl+Space+{key} combinations since Ctrl-Space is used for mode switching in Asian languages.
15) Try to save navigation context.
e.g. in Workbench / Preferences, we now remember which page you had selected last. This avoids having to navigate through the list each time
16) Assign a specific person on the team to be responsible for accessibility on your project.
17) Test for accessibility.
Have your team hold an occasional "unplug your mouse day" where they try to use the product using keyboard only. Get a copy of JAWSTM (http://www.freedomscientific.com/) and ensure that your UI is usable with it
