The UI Accessibility Programming Interface

The UI Accessibility programming interface consists of two informal protocols, one class, a function, and a handful of constants:

• The UIAccessibility informal protocol. Objects that implement the UIAccessibility protocol report their accessibility status (that is, whether they are accessible) and supply descriptive information about themselves. Standard UIKit controls and views implement the UIAccessibility protocol by default.

• The UIAccessibilityContainer informal protocol. This protocol allows a subclass of UIView to make some or all of the objects it contains accessible as separate elements. This is particularly useful when the objects contained in such a view are not themselves subclasses of UIView and, for this reason, are not automatically accessible.

• The UIAccessibilityElement class. This class defines an object that can be returned through the UIAccessibilityContainer protocol. You can create an instance of UIAccessibilityElement to represent an item that isn’t automatically accessible, such as an object that does not inherit from UIView, or an object that does not exist.

• The UIAccessibilityConstants.h header file. This header file defines the constants that describe the traits that an accessibility element can exhibit and the notifications that an application can post.

Accessibility Attributes

The attributes that describe an accessible user interface element make up the core of the UI Accessibility API. VoiceOver supplies attribute information to users when they access or interact with a control or view.

Attributes are also the components of the programming interface that you’re most likely to use. This is because attributes encapsulate the information that differentiates one control or view from another. For standard UIKit controls and views, you might just need to ensure that the default attribute information is appropriate for your application; for custom controls and views, you might have to supply most of the attribute information.

The UI Accessibility programming interface defines the following attributes:

• Label. A short, localized word or phrase that succinctly describes the control or view, but does not identify the element’s type. Examples are “Add” or “Play.”

• Traits. A combination of one or more individual traits, each of which describes a single aspect of an element’s state, behavior, or usage. For example, an element that behaves like a keyboard key and that is currently selected can be characterized by the combination of the Keyboard Key and Selected traits.

• Hint. A brief, localized phrase that describes the results of an action on an element. Examples are “Adds a title” or “Opens the shopping list.”

• Frame. The frame of the element in screen coordinates, which is given by the CGRect structure that specifies an element’s screen location and size.

• Value. The current value of an element, when the value is not represented by the label. For example, the label for a slider might be “Speed,” but its current value might be “50%.”

Accessibility elements provide content for attributes, whether that content is supplied by default or by you. An accessibility element always provides content for the frame and label attributes. The frame attribute is required because an accessibility element must always be able to report its position in the user interface. (Note that an object that inherits from UIView includes the frame attribute by default.) The label attribute is required because it contains the name or description of the accessibility element that VoiceOver speaks.

An accessibility element is not required to provide content for the hint and traits attributes, if these attributes do not apply to the element. For example, an element that does not perform an action does not need to provide a hint.

An accessibility element provides information for the value attribute only when the element’s contents are changeable and cannot always be described by the label. For example, a text field that contains an email address might have the label “Email address,” but its contents depends on user input and is usually of the form “username@address.” Figure 1-1 shows some of the information VoiceOver might provide.

VoiceOver users rely on the labels and hints they hear to help them use your application. For this reason, it’s especially important to make sure that every accessible user interface element in your application provides accurate and informative descriptions. For standard UIKit controls and views, the default attribute information is often appropriate, but you should inspect these elements to make sure. For custom controls and views, you may have to supply some or all of this information yourself. For some guidelines on how to do this, see Crafting Useful Labels and Hints.