For most everyone you know, computers are simply part of everyday life; for office workers, children, grandparents. That is, everybody who has good eyesight, good hearing, and full use of both hands.

But for those with any kind of disability, using computers has often been problematic.

That situation is changing, through a combination of new technologies, federal law, and an increased awareness that computers ought to be usable by everybody, including those with disabilities.

Apple has been working hard on Universal Access and it's time for you, the developer, to incorporate Universal Access into your application if you haven't done so already. This article guides you through the reasons you will want to provide Universal Access, the architecture underlying the technology, and how to get started incorporating these features into your application.

New in Mac OS X v10.4 Tiger is VoiceOver, an accessibility interface that gives you magnification options, keyboard control and spoken English descriptions of what's happening on screen.

What Is Universal Access?

Not everybody is fully able. Some people are born with disabilities, others acquire them at work (think of repetitive-stress injuries), and anyone who lives long enough acquires some disabilities. These people want, need, and deserve to use computers, too.

Universal Access is Apple's collective name for the Mac OS X technologies, features, and components that provide users with disabilities with access to Macintosh computers. This includes things like Apple's voice-independent speech recognition technology, the Zoom view feature for users with vision impairments, and the TextEdit component of Mac OS X, which can help users with learning disabilities through its ability to read a document's text aloud using a synthesized voice. Table 1: Major Features of Universal Access contains a list of the technologies, features, and components included in Universal Access, including VoiceOver, the newest addition to the accessibility features.

Why Universal Access Is Important To You

Although many Universal Access features work independent of your application, you will need to put some effort into making your application fully accessible to users with disabilities (a process that Apple calls access-enabling). There are several important reasons why you should access-enable your application:

• Because you want to make more money.

  Apple conservatively estimates that 20 percent of the general population (which includes the ever-influential "baby boomer" generation) will benefit from one or more of the universal-access features in Mac OS X. Access-enabling your applications significantly increases the number of people who will be interested in buying them.

• Because your customers will expect it.

  As Apple continues to advertise its Universal Access as a key benefit of the Mac OS X platform, Macintosh users will begin to expect its universal-access features to be available throughout their Macintosh computers. If a universal-access feature exists at the system level but "disappears" when they start using your application, you can be sure they will let you know that, as far as they are concerned, your application has a bug in it that needs fixing now. The general Macintosh community will find out about this problem, and you'll lose many potential customers to competing products that are access-enabled.

• Because the law requires it.

  Section 508, which is an amendment to the U.S. Rehabilitation Act of 1973, requires that information-based products and services must be accessible to people with disabilities. By making sure that your products meet Section 508 guidelines, you ensure that they may be considered for purchase by a growing number of government, education, and commercial markets that require conformity to these guidelines.

• Because you make your application better.

  By making your application accessible, you make it a better app for every user, not just those who need accessibility assistance. For example, keyboard shortcuts and good design that reduces the number of steps to complete a process are just as important and just as well-loved by power users (that is, your app's most die-hard fans) as it is by those who require accessibility.

• Because it's the right thing to do.

  Access-enabling your application will add to the quality of life of many people with disabilities and will reduce the barriers to equal opportunity that they face every day. In addition, doing so will help increase marketplace acceptance of the Macintosh platform, as well as increase the quality of your application and reputation of your company. In short, it's the right thing to do.

Apple's Accessibility Architecture

Before you can understand how to modify your application to make it access-enabled, you must first understand Apple's accessibility architecture—that is, the architecture that enables both of Apple's user interfaces—the visual Aqua interface, and VoiceOver—to interact with the various user-interface objects of a Cocoa or Carbon application.

Apple's commitment to Universal Access reflects an increasing awareness that computers need to be accessible to everyone. Just as, in the 1990s, the computer industry recognized the necessity of making computers accessible to people who use different languages through internationalization, universal accessibility will become the recognized necessity of this decade.

Ever since its inception in 1976, Apple has supported people with disabilities by making computers that supported alternative modes of access. Apple continues its support for this population, and it has found that many other users also benefit from various Universal Access features. In particular, the first generation of people for whom the personal computer is a tool of everyday life is an extremely important audience to consider. As they age, they will expect computers to provide accessibility features that will enable them to continue to be productive and creative.

View and Accessibility Hierarchies

You are probably very familiar with the Apple view hierarchy, which structures how various user-interface objects interact to create the application's behavior and visual appearance. The left half of Figure 1 shows a typical view hierarchy. Coexisting with an application's view hierarchy is an analogous accessibility hierarchy, shown on the right side of Figure 1, that structures how many of those same user-interface objects interact with the operating system's accessibility subsystem.

An application's accessibility hierarchy will probably be slightly different from its view hierarchy; see Figure 1. The reason for this is very important: Every parent-child pair in the accessibility hierarchy translates to a keystroke that the user must make to switch the focus from one to the other. For this reason, you should "remove" any view that the user does not need to interact with. Both Cocoa and Carbon include mechanisms for removing an interface object from the accessibility hierarchy; such elements are called ignored objects.

For example, the Button in the view hierarchy of Figure 1 is simply a container for its child view, a Button Cell (which contains the behavior of the Button).

Figure 1: Apple's View and Accessibility Hierarchies

Cocoa and Carbon implement accessibility objects in an analogous way, using different mechanisms to accomplish the same effect. Accessibility objects implement the Accessibility protocol—kEventClassAccessibility Carbon Events in Carbon, and the NSAccessibility protocol in Cocoa—which determines their behavior in certain situations. For example, when a certain radio button is sent a message that "asks" what kind of object it is, it should "respond" with the information that it is a radio button. Similarly, when the user changes the position of a slider, it should "announce" its new value to the system.

Attributes

Each accessibility object has a number of attributes associated with it, each of which has a value. When other software needs to know about a given accessibility object, it does so by retrieving the value of the appropriate attribute. Some attributes simply return a single value, while others return a value determined by the combination of the attribute and a single parameter value associated with the attribute.

Here are the most important attributes associated with an object's accessibility, shown in Table 2:

Table 2: Attributes Associated with an Object's Accessiblity

The Accessibility protocol includes methods that:

• return an array of all the attributes belonging to the current object
• return an array of all the attribute-parameter combinations belonging to the current object
• return the value of a given attribute for the current object
• return the value of a given attribute-parameter combination belonging to the current object
• determine whether or not a given attribute's value can be changed

Actions

An accessibility object may have one or more actions associated with it; such actions represent all the user-initiated operations that may be performed upon the object, usually by clicking the mouse or pressing the Return key, as shown in Table 3:

Table 3: Actions Associated with an Object

The Accessibility protocol includes methods that:

• return an array of all the actions valid for the current object
• return a localized text string that describes a given action belonging to the current object
• perform a given action upon the current object

Notifications

When certain events occur, the accessibility architecture informs other software of the event that has occurred by sending it a notification. Examples of such events include application events (the application being activated, deactivated, hidden, shown), window events (new window appears, window moves or changes size, window moves to or from the Dock), and events belonging to a single user-interface element (element gains focus, changes value, or is destroyed).

Hit-Testing and Keyboard Focus

User interfaces need to be able to determine, for a given point on the screen, the "deepest" accessibility object in the accessibility hierarchy that contains the point. The Accessibility protocol includes a method that, when invoked on a given accessibility object, returns the "deepest" accessibility object containing a given point.

At any given moment, some accessibility object on the screen has the keyboard focus—that is, any keyboard event will be sent to that object. User interfaces need to be able to determine which is the "deepest" accessibility object that has the keyboard focus. The Accessibility protocol includes a method that, when invoked on a given accessibility object that has the focus, returns the "deepest" child element that has the keyboard focus.

Access-Enabling Your Application

You can access-enable your application by taking the steps described in the following sections. Applications that use no custom user-interface widgets will require, in general, very little work because the default widgets already contain most of the coding needed to support Universal Access. The more custom user-interface widgets an application uses, the more effort is required to access-enable it. Carbon-based applications that use their own custom view systems (as opposed to the Control Manager and/or HIView) will also take additional effort to access-enable them.

Step One: Implement the Apple Accessibility Protocol

Though this step may require considerable work, it is the most important. All the user-interface elements in your application (be it a Carbon or a Cocoa application) must implement the appropriate support for accessibility objects, attributes, actions, notifications, hit-testing, and keyboard focus. To get you started, Apple provides a tool, the UI Element Inspector, that displays accessibility information for whatever the mouse is pointing to.

Custom user-interface elements will require some work to make them access-enabled. If they are subclasses of Apple-provided widgets, the only accessibility code that you need to add will relate to the customizations that you have added. If your custom user-interface element is not based on an Apple-provided widget, it may be a good idea for you to rewrite your user-interface element as a subclass of the appropriate widget. By doing so, your application will automatically receive a number of benefits that result from Apple's current and future improvements to its system software.

Be sure to "remove" from the accessibility hierarchy all the user-interface elements that the user does not need to access. Doing so decreases the number of keystrokes that users need to move among the user-interface elements that they do need to access.

Step Two: Full Keyboard Access

Unplug your mouse and try to use your application using only the keyboard. If you can't perform every task your application is capable of, you've got some work ahead of you.

Your first step in accomplishing this task is to acquaint yourself with the key combinations in Mac OS X that support full keyboard access, as well as the various keyboard shortcuts that Mac OS X provides. See the For More Information section below for links to two separate web pages that provide this information.

After you have acquainted yourself with the key combinations and keyboard shortcuts that Mac OS X provides, try to use the keyboard to access and manipulate all the user-interface elements in your application. In some cases, you may not be able to move the focus to a given element; in others, you may be able to access the element but not manipulate it. In this way, you can easily determine which user-interface elements need additional work.

Implementing Mouse-Free Tasks

"But," you may say, "how can I possibly move the mouse cursor with keystrokes without making my application totally unusable?" The answer is that you can't, and you shouldn't try. Your application shouldn't duplicate mouse functionality; instead, it should provide a usable and equivalent way to accomplish any task using only the keyboard. For example, if your application enables users to drag-and-drop an element from one location to another, one solution is to make it possible for users to select the element, perform a cut operation, move to the destination, and perform a paste operation—all with keystrokes only.

Of course, users will appreciate innovative solutions that minimize the number of keystrokes needed to perform a given task. If an often-performed operation requires too many keystrokes, consider providing a menu item and keyboard shortcut to perform the operation.

Unfortunately, the mouse is part of numerous well-established ways of getting work done on a computer, including such control gestures as drag-and-drop (to move an element), drag-and-release (to select multiple elements), shift-click (to toggle inclusion in a selection), double-click, triple-click, plus numerous variations that include using the Option key, Control key, Shift key, and the right mouse button. If your application uses any such control gesture as the only way to accomplish a task, you should provide a keyboard-only equivalent.

One final note: Full keyboard access should be the last thing you do to make your application access-enabled. The reason for this is that Step One, implementing the Apple accessibility protocol, automatically implements a lot of keyboard-only accessibility, without which the task of implementing full keyboard access would be more difficult or impossible.

Introducing VoiceOver

Tiger includes a major new adaptive technology feature that will benefit users with visual and learning disabilities: VoiceOver. This new technology provides a complete sound-and-keyboard-based user interface alongside the Mac OS X Aqua visual user interface.

VoiceOver makes possible for users with vision and learning disabilities to navigate the Mac OS X interface and interact with application and system controls. Such users will interact with Mac OS X using the keyboard, and Mac OS X will respond with audible speech and sound feedback—for example, Mac OS X will speak the name of the active window, and it will provide descriptive feedback when the user changes the value of a slider control.

VoiceOver is fundamentally different from the third-party "screen reader" utilities that people with visual impairments have traditionally used in that the spoken interface is an integral part of the operating system. Because VoiceOver is built into Mac OS X, it is available on every Macintosh computer running Tiger and later versions of Mac OS X. It has the high stability and ease-of-use for which Mac OS X is known, and it will provide a single, consistent spoken interface for both Mac OS X and all access-enabled third-party applications.

Conclusions

Modifying your application to use the appropriate Carbon or Cocoa frameworks may require significant work, but doing so has three important benefits:

• It accomplishes much of the work needed to make your application access-enabled.
• It decreases the amount of work necessary to give your application full keyboard access.
• It extends the effective lifetime of your application, because many of Apple's future innovations and performance increases will be built upon these frameworks (especially Cocoa).

Making your application access-enabled is part of delivering a professional product. Doing so today will give you a competitive advantage over your competitors. In the future, it will be a checklist feature whose absence will automatically remove your application from customers' consideration. Simply put, access-enabling your application is the right thing to do—for both you and your customers.

For More Information

General

• The main Apple Accessibility webpage
• VoiceOver Apple's new spoken interface
• Getting Started With Accessibility
• The UI Element Inspector works with both Carbon and Cocoa.

Cocoa Programming

• Enabling Accessibility in Your Cocoa Application
• NSAccessibility API documentation

Carbon Programming

• Empowering Your Carbon Application with the VoiceOver Accessibility Interface
• Designing Applications for Users with Disabilities
• The Benefits of HIToolbox: The Evolving Widget Set, an introduction to HIView

Other

• Accessibility Sample Code webpage
• Documentation on key combinations for full keyboard access and system-wide keyboard shortcuts is found in the Human Interface Guidelines.

Updated: 2006-09-06