---

Communication With Accessibility Objects

At the heart of accessibility is the communication between an assistive application and the accessibility objects that represent your application’s user interface. This communication can be divided into two categories:

• Messages sent by an assistive application to get information about an accessibility object and to request the performance of actions. An accessibility object responds to these messages by returning attribute values, performing actions, or changing attribute values.

• Notifications triggered by accessibility objects that assistive applications can listen for. These notifications tell an interested assistive application about changes in the state of an accessibility object.

If you use only standard, noncustom Cocoa or Carbon objects in your application, most of this communication is transparent to you. In some cases, you might have to create a custom response to a message, but this is unlikely. It is even less likely that you will have to handle notifications if you use only standard objects.

In this section:

Messages
Notifications
Hit-Testing and Keyboard Focus

Messages

An assistive application communicates with your application by sending messages to accessibility objects. In Carbon, these messages are transmitted as Carbon events. In Cocoa, these messages result in calls to methods of the NSAccessibility protocol. For more details about the framework-specific implementation of messages, see Accessibility Programming Guidelines for Cocoa and Accessibility Programming Guidelines for Carbon.

In HIObject.h, Mac OS X defines a handful of messages. The following lists the types of messages an assistive application can send to an accessibility object:

• Get a list of the accessibility object’s attributes

• Get the value of a specific attribute

• Check to see if the value of a specific attribute can be set

• Set the value of a specific attribute

• Get a list of the accessibility object’s actions

• Get the description of an action

• Tell the accessibility object to perform a specific action

• Determine which accessibility object is under the mouse pointer (hit testing)

• Register or unregister for notifications

Like the set of actions, the set of messages to which an accessibility object can respond is small. These messages give the assistive application a great deal of control, however. For example, by getting and setting attributes, an assistive application can do things like the following:

• Read the value of a slider control

• Traverse the object hierarchy to find all the accessibility objects (such as controls, embedded controls, and table cells) within a window

• Check to see if a control is enabled

Notifications

In addition to responding to messages from assistive applications, accessibility objects also broadcast any significant changes that occur in the user interface objects they represent. For example, if the keyboard focus changes to a new text field, a new window becomes active, or a control’s title changes, the accessibility objects for these objects send out notifications.

An assistive application chooses to register for the notifications it is interested in.

An accessibility object can send notifications to indicate any of the following status changes:

• The object’s value changed

• The object was destroyed

• The keyboard focus changed

Unless you are creating accessibility objects to represent custom user interface objects, it is unlikely you will have to write code to send notifications. Both Carbon and Cocoa automatically broadcast the appropriate notifications for standard objects.

Hit-Testing and Keyboard Focus

To a sighted user, the location of the cursor is easy to discern. Similarly, a sighted user can usually tell which object in the user interface has keyboard focus. An assistive application, on the other hand, must query an application to determine which object has keyboard focus or is under the mouse pointer. An accessibility object provides answers to these queries by returning the values of various attributes.

Although you implement hit-testing differently depending on whether you’re using Carbon or Cocoa, the basic procedure is for an assistive application to ask the application to return the accessibility object under the cursor. The request is recursively passed down the application’s accessibility hierarchy until it reaches the deepest, unignored accessibility object that contains the mouse pointer.

Accessibility objects also must support queries regarding keyboard focus. An accessibility object stores focus information in its focused attribute. The initial query from the assistive application is for the focused attribute of the application-level accessibility object. This query, too, is passed down the application’s accessibility hierarchy until it reaches the deepest, unignored accessibility object whose focused attribute is true. As with hit-testing, how the keyboard focus is actually determined from lower-level objects varies depending on whether you use Carbon or Cocoa.

---