Design considerations for accessible applications

To create an application that is accessible to people with disabilities, keep the following design considerations in mind.

• Use text as the primary means of communicating information. Text and rich text are accessible in almost every situation.
• Use the Alternate text tag on all images and applets.

  Both images and Java™ applets allow you to specify a short piece of text to be displayed with the graphical object. Typically the alternate text appears only when the object is loading or when image or applet loading is turned off in browser preferences. However, alternate text is also used by screen reader software to describe the contents of an object. Specify alternate text on the Info tab (i) of the Picture and Java™ Applet Properties box.

• Echo the action button tasks in the Action menu and echo the forms you create in the Create menu.

  Screen readers cannot always provide information about action buttons. For this reason, when you design an application, you should provide users with an alternative way to trigger actions and create forms. Echoing action button tasks in menus provides this alternative route. To echo an action button on the Action menu, open the properties box for the action and select "Include in Action Menu." To provide access to a form that might otherwise be triggered by an action button in a view, for instance, open the properties box for the form and select "Include in menu."

• Place the most frequently accessed menu items at the beginning of the menu list.

  The vertical order in which the Action buttons appear in the action pane indicates the order in which they appear on the Action menu and bar. You can create the order in which forms appear on the Create menu. You can cut and paste the most frequently used actions to the beginning of the list in the action pane. To place the form that is most often accessed by users at the beginning of the Create menu list, insert the number 1 followed by a period (1.) in front of the name in the form's name field. You can number the remaining forms accordingly to control their order in the menu list.

• Check that the accelerator keys assigned to menu items make sense.

  If an application has more than one menu item that starts with the same letter, Notes® assigns a default accelerator key using the first letter not already in use. If the accelerator key assigned to an action or form does not make sense, you can force the assignment of a specific key. In the name field for the action or form, add an underscore before the letter you want to assign as the accelerator key. For example, if you want to assign p as the accelerator key for the form entitled Complete evaluation, enter "Com_plete evaluation" in the form's name field.

Avoid:

• Using Java™ applets as the sole means of navigating or performing an action. Java™ accessibility is currently not widely supported, and a keyboard-only user cannot navigate to a Java™ applet in many browsers.
• Excessive use of embedded objects. Although these are keyboard-accessible, navigating through too many objects can be a burden for keyboard-only users.
• Excessive use of framesets. It is laborious for keyboard-only users to navigate through framesets. The fewer frames used in an application, the easier it will be for a keyboard user to navigate.
• Using color and graphics as the sole means of communicating meaning in your application. To test if your application is legible for color-blind users, set your display to monochrome and view all graphics.
• Using text smaller than 10 point Helvetica. Some operating systems support a large font user preference, but this preference is not respected by all objects in an application.
• Graphical navigators. Use outline controls instead as they are screen reader accessible.
• Layout regions.

If accessibility is a major priority for your application, you may want to consider creating an alternate interface for your application using only text and non-embedded controls.