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 YouAlthough 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:
Apple's Accessibility ArchitectureBefore 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 HierarchiesYou 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— AttributesEach 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:
ActionsAn 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:
NotificationsWhen 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 FocusUser 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 ApplicationYou 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 ProtocolThough 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 AccessUnplug 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 VoiceOverTiger 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. ConclusionsModifying your application to use the appropriate Carbon or Cocoa frameworks may require significant work, but doing so has three important benefits:
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 InformationGeneral
Cocoa ProgrammingCarbon Programming
Other
Updated: 2006-09-06 |