5-1.2 General Requirements

Accessibility is accomplished by designing software that accommodates the widest range of users, including those with disabilities. Listed below are some general requirements that will help the Postal Service ensure continued accessibility of software applications and operating systems:

• The Postal Service will develop and procure software applications that take advantage of hardware and operating system built–in accessibility features when those features are available to both end users and software developers.
• The Postal Service will maintain standards for the following categories of assistive technologies that people with disabilities use to access software applications and operating systems:
• Screen magnifiers: Help visually impaired people by allowing them to enlarge any part of the screen (i.e., as with a magnifying glass).
• Screen readers: Help people who are blind by making on–screen information available as synthesized speech or for display as refreshable Braille.
• Voice input aids: Help mobility– or dexterity–impaired people by allowing them to control the computer with their voice instead of with a mouse or keyboard.
• On–screen keyboards: Help people who are unable to use a standard keyboard by providing an on–screen keyboard that can be used with a pointing device.
• Keyboard filters: Help people who have trouble typing by compensating for erratic motion, tremors, or slow response time.
• Alternative input devices: Help people who would prefer to control their computer with a device other than a keyboard or mouse.
• The Postal Service will develop software applications that maximize the capabilities of the accessibility features installed and activated by a user (e.g., native hardware and operating system features, as well as installed accessibility aids). Software developers should do the following:
• Support the native operating system and activate the accessibility features for the major operating systems that are integrated with input and output devices (e.g., keyboard, sound, display, or mouse).
• Use standard controls for the particular operating systems where possible (e.g., menus, buttons, lists, or windows). These standard controls often already support the native operating system accessibility features. Using them will often eliminate the need for software to provide explicit accessibility support, unless the behavior of the standard controls has been enhanced.
• Be careful when using custom controls or enhancing standard controls, because accessibility aids may have difficulty identifying them (i.e., accessibility aids require specific information to work successfully with screen elements). When custom or enhanced standard controls are used, developers must use appropriate accessibility interfaces or application programming interfaces (APIs) (e.g., Sun's Java Access Bridge, Microsoft Active Accessibility, window messaging, off–screen model, etc.) to provide object information to accessibility aids. The information that must be provided by objects includes name, location, type, associated values, parent control, logical order for navigation, and event notifications, such as focus gain or loss.
• Provide flexibility in using a variety of input methods (e.g., keyboard or mouse) and output methods (e.g., color, sound, images, or text).
• Detect if accessibility aids are in use and configure the software applications automatically. For example, determine when a screen reader is in use so that the software can be reconfigured.