Designing your application with accessibility in mind not only allows you to reach a larger group of users, it results in a better experience for all your users. You’ve already made the design decision to develop an application that runs in Mac OS X. Now, make sure you can deliver the Macintosh experience to all your users.
This chapter describes some of the things you should consider when developing your application. If your application includes support for the accessibility-related features this chapter describes, it will be even easier to access-enable.
Although this chapter is of most use to developers who are in the design phase of an application, it presents information about accessibility concerns all developers should know.
As a first step in the design process, you should familiarize yourself with the information in Apple Human Interface Guidelines. That document presents the best practices of application design that help you create a first-rate application for Mac OS X. In addition, Apple Human Interface Guidelines provides detailed specifications for designing and implementing an intuitive, consistent, and aesthetically pleasing user interface that delivers the superlative experience Macintosh users have come to expect.
During the design process, you also should be aware of the accessibility perspective on many basic design considerations. This section describes how you can support accessibility in your most fundamental design decisions. As with most accessibility design considerations, incorporating them with your design will result in a better user experience for all users.
The design principles described here are especially important to consider when developing an accessible application:
Support full keyboard navigation. For many users, a mouse is difficult, if not impossible, to use. Consequently, a user should be able to perform all your application’s functions using the keyboard alone.
Taking this consideration into account will make access enabling your application an even easier task.
Don’t override built-in keyboard shortcuts. This applies both to the keyboard shortcuts Mac OS X reserves (listed in the Apple Human Interface Guidelines appendix “Keyboard Shortcuts Quick Reference”) and to the accessibility-related keyboard shortcuts (listed in “Accessibility Keyboard Shortcuts”). As a general rule, you should never override reserved keyboard shortcuts. In particular, you should take care not to override accessibility-related keyboard shortcuts or your application will not be accessible to users who enable full keyboard access.
A corollary to this principle is to avoid creating too many new keyboard shortcuts that are specific to your application. Users should not have to memorize a new set of keyboard commands for each application they use.
Provide alternatives for drag-and-drop operations. If your application relies on drag-and-drop operations in its workflow, you should provide alternate ways to accomplish the same tasks. This may not be easy; in fact, it may require the design of an alternate interface for applications that are heavily dependent on drag and drop.
For example, the original Mac OS X Finder application was designed to provide a simple drag-and-drop interface to the file system. In keeping with its accessibility goals, however, the Finder in Mac OS X version 10.2 and later adds keyboard support that allows users to copy and move files using keyboard commands instead of the mouse.
Make sure there’s always a way out of your application’s workflow. This is important for all users, of course, but it’s essential for users of assistive technologies. A user relying on an assistive application to use your application may have a somewhat narrower view of your application’s user interface. For this reason, it’s especially important to make cancelling operations and retracing steps easy.
Following the guidelines in “Basic Design Requirements” will help you design an easy-to-use application that will be easy to access-enable. There may be specific information about particular disabilities you don’t know, however, and this information is useful to keep in mind during the design process.
The following sections describe some broad categories of disabilities and offer suggestions for specific design solutions and adaptations you can make. The main theme of these suggestions is to provide as many alternate modes of content display as possible. The more ways your application presents information, the more likely your users will be to find the way that suits them best.
Visual disabilities include blindness, color blindness, and low vision. In addition to making your application accessible to assistive applications, such as screen readers, you should also consider the following:
Although color can greatly enhance a user interface, make sure it is not the only source of information. A color blind user may not be able to distinguish between two objects that differ only in color.
Provide an audio option to all visual cues and feedback. Your application should make it easy to replace visual communication with audio communication.
Provide an option to present images and animated content in an alternate manner. If your application displays an image or animation, consider providing your own succinct descriptions of these elements so blind or low-vision users can benefit from the information they convey.
People with hearing disabilities may have difficulty distinguishing your application’s sound effects from ambient noise or may not be able to hear them at all. Users without hearing disabilities may find themselves in circumstances in which audio output from an application is inappropriate (in a library, for example). Be sure to consider these points as you design the audio output of your application.
Your application should not override the audio-output settings the user selects in System Preferences. In addition, you should provide a visual option to all audio cues and feedback. Your application should make it easy to replace audio communication with visual communication. For example, a “beep” can be replaced or accompanied by a flash of the display screen.
People with motor disabilities may need to use alternatives to the standard mouse and keyboard input devices. Other users may have difficulty with the fine motor control required to double-click a mouse or to press key combinations on the keyboard. Users with cognitive or learning disabilities may need extra time to complete tasks or respond to alerts.
For the most part, support for motor disabilities is provided at the hardware or operating system level. Mac OS X provides many such solutions in the Universal Access preferences. The Sticky Keys feature, for example, allows a user to type the keys in a key combination sequentially, instead of simultaneously. As an application developer, therefore, the most important thing you can do is to access-enable you application so your users can deploy the assistive technologies of their choice.
A feature such as Sticky Keys can also be helpful to a user with a cognitive or learning disability that makes it difficult to perform simultaneous tasks. An application that provides its output in both visual and auditory modes (especially simultaneously) can enhance comprehension. Users with such disabilities also benefit from the redundancy provided by an application that employs both audio and visual output.
In addition to making your application accessible, you should consider incorporating the following features:
Provide options to adjust the length of expected response times. Users who have difficulty quickly responding to application events benefit from having extra time to respond. When a timed response is required—such as notification that a regularly scheduled action is about to take place—you should provide at least one response method that does not require users to respond within the timed interval. Alternatively, you should provide at least one method that allows users to adjust the response time to at least five times the default setting.
Avoid using regularly blinking cursors or other objects on screen. The frequency of a blinking object must not be in the range of 2 hertz to 55 hertz, inclusive. Objects that blink in this frequency range can cause medical complications, such as seizures, in some people.
Last updated: 2008-03-11