The following is a list of guidelines for creating features for the Commerce Manager Client:

• 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.
• 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 (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
• 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.
• 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 menu bar (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 within Eclipse from the General > Keys preference page, to avoid collision.
• Avoid Alt+key, Ctrl+Alt+key and Ctrl+Space+key combinations.
  • Alt+key combinations may conflict with menu mnemonics.
  • Ctrl+Alt+key combinations can conflict with entering special characters on international keyboards (alt Gr = Ctrl+Alt).
  • Ctrl+Space+key combinations can conflict with Ctrl-Space, used for mode switching in Asian languages.
• 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 JAWS(tm) and ensure that your UI is usable with it.