The Core iOS Developer’s Cookbook, Fifth Edition (2014)

The UIAccessibility protocol includes the following properties:

accessibilityTraits—A set of flags that describe a UI element. These flags specify how items behave or how the interpretive system should treat them. For example, these traits include state, such as selected or enabled, and behavior, such as behaving like a button.

accessibilityLabel—A short phrase or word that describes the view’s role or the control’s action (for example, Pause or Delete). Labels can be localized.

accessibilityHint—A short phrase that describes what user actions do with this element (for example, Navigates to the home page). Hints can also be localized.

accessibilityFrame—A rectangle specifically for non-view elements, which describes how the object should be represented onscreen. Views use their normal UIView frame property.

accessibilityPath—A UIBezierPath that can be used instead of the accessibility frame for elements that are non-rectangular.

accessibilityValue—The value associated with an object, such as a slider’s current level (for example, 75%) or a switch’s on/off setting (for example, ON).

Accessibility in IB

The IB Identity Inspector > Accessibility pane (see Figure 15-1) enables you to add accessibility details to UIKit elements in your interface. These fields and the text they contain play different roles in the accessibility picture. There’s a one-to-one correlation with the UIAccessibilityprotocol and the inspector elements presented in IB. As with direct code access, labels identify views; hints describe them. In addition to these fields, you’ll find a general Accessibility Enabled check box and a number of Traits check boxes.

Figure 15-1 IB’s Identity Inspector lets you specify object accessibility information.

Enabling Accessibility

The Enabled check box controls whether a UIKit view works with VoiceOver. To declare an element’s accessibility support, set the isAccessibilityElement property to YES in code or check the Accessibility Enabled box in IB (see Figure 15-1). This Boolean property allows GUI elements to participate in the accessibility system. By default, all UIControl instances inherit the value YES.

As a rule, enable accessibility unless the view is a container whose subviews need to be accessible. Enable only the items at the most direct level of interaction or presentation. Views that organize other views don’t play a meaningful role in the voice presentation. Exclude them.

Table view cells offer a good example of accessibility containers (that is, objects that contain other objects). The rules for table view cells are as follows:

A table view cell without embedded controls should be accessible.

A table view cell with embedded controls should not be accessible. Its child controls should be.

Nonaccessible containers are responsible for reporting how many accessible children they contain and which child views those are. See Apple’s Accessibility Programming Guide for iOS for further details about programming containers for accessibility. Custom container views need to declare and implement the UIAccessibilityContainer protocol.

Traits

Traits characterize UIKit item behaviors. VoiceOver uses these traits while describing interfaces. As Figure 15-1 shows, there are numerous possible traits you can assign to views. Select the traits that apply to the selected view, keeping in mind that you can always update these choices programmatically.

Traits help characterize the elements in your interface to the VoiceOver system. They specify how items behave and how VoiceOver should treat them. You set them via the accessibilityTraits property, by selecting a single flag or OR’ing two or more flags. You can also set them in IB, as you saw in Figure 15-1. These traits vary in how they operate and how VoiceOver uses them.

At the most basic, default level, there’s the “no trait” flag:

UIAccessibilityTraitNone—The element has no traits.

There are also flags that describe what the user element is. These include the following:

UIAccessibilityTraitButton—The element is a button.

UIAccessibilityTraitLink—The element is a hyperlink.

UIAccessibilityTraitStaticText—The element is unchanging text.

UIAccessibilityTraitSearchField—The element is a search field.

UIAccessibilityTraitImage—The element is a picture.

UIAccessibilityTraitKeyboardKey—The element acts as a keyboard key.

UIAccessibilityTraitHeader—The element is a content header.

Apple’s accessibility documents request that you only check one of the following four mutually exclusive items at any time: Button, Link, Static Text, or Search Field. If a button works as a link as well, choose either the button trait or the link trait but not both. You choose which best characterizes how that button is used. At the same time, a button might show an image and play a sound when tapped, and you can freely add those traits.

There are a few basic state flags, which discuss the selection, adjustability, and interactive state of the object:

UIAccessibilityTraitSelected—The element is currently selected, such as in a segmented control or the selected row in a table.

UIAccessibilityTraitNotEnabled—The element is disabled, disallowing user interaction.

UIAccessibilityTraitAdjustable—The element can be set to multiple values, as with a slider or picker. You specify how much each interaction adjusts the current value by implementing the accessibilityIncrement and accessibilityDecrement methods.

UIAccessibilityTraitAllowsDirectInteraction—The user can touch and interact with the element.

If an element plays a sound when interacted with, there’s a flag for that as well:

UIAccessibilityTraitPlaysSound—The element will play a sound when activated.

Finally, a handful of states caution and describe how an element behaves and interacts with the larger world:

UIAccessibilityTraitUpdatesFrequently—The element changes often enough that you won’t want to overburden the user with its state changes, such as the readout of a stopwatch.

UIAccessibilityTraitStartsMediaSession—The element begins a media session. Use this to limit VoiceOver interruptions when playing back or recording audio or video.

UIAccessibilityTraitSummaryElement—The element provides summary information when the application starts, such as the current settings or state.

UIAccessibilityTraitCausesPageTurn—The element should automatically turn the page when VoiceOver finishes reading its text.

As Figure 15-1 demonstrates, most of these traits (but not all) can be toggled off or on through the IB Identity Inspector pane. If you need finer-grained control, set the flags in code.

Labels

Set an element’s label by assigning its accessibilityLabel property. A good label tells the user what an item is, often with a single word. Label an accessible GUI the same way you’d label a button with text. Edit, Delete, and Add all describe what objects do. They’re excellent button text and accessibility label text.

But accessibility isn’t just about buttons. Feedback, User Photo, and User Name might describe the contents and function of a text view, an image view, and a text label. If an object plays a visual role in your interface, it should play an auditory role in VoiceOver. Here are a few tips for designing your labels:

Do not add the view type into the label. For example, don’t use “Delete button,” “Feedback text view,” or “User Name text field.” VoiceOver adds this information automatically, so “Delete button” in the identity pane becomes “Delete button button” in the VoiceOver playback.

Capitalize the label but don’t add a period. VoiceOver uses your capitalization to properly inflect the label when it speaks. Adding a period typically causes VoiceOver to end the label with a downward tone, which does not blend well into the object-type that follows. “Delete. button” sounds wrong. “Delete button” does not.

Aggregate information. When working with complex views that function as a single unit, build all the information in that view into a single descriptive label and attach it to that parent view. For example, in a table view cell with several subviews but without individual controls, you might aggregate all the text information into a single label that describes the entire cell.

Label only at the lowest interaction level. When users need to interact with subviews, label at that level. Parent views, whose children are accessible, do not need labels.

Localize. Localizing your accessibility strings opens them up to the widest audience of users.

Hints

Assign the accessibilityHint property to set an element’s hint. Hints tell users what to expect from interaction. In particular, they describe any nonobvious results. For example, consider an interface where tapping on a name—for example, John Smith—attempts to call that person by telephone. The name itself offers no information about the interaction outcome, so offer a hint telling the user about it—for example, “Places a phone call to this person,” or, even better, “Places a phone call to John Smith.” Here are tips for building better hints:

Use sentence form. Start with a capital letter and end with a period. Do this even though each hint has a missing, implied subject. For example, in “Clears text in the form,” the implied subject is “This button.” Using sentence format ensures that VoiceOver speaks the hint with proper inflection.

Use verbs that describe what the element does, not what the user does. “[This text label] Places a phone call to this person.” provides the right context for the user. “[You will] Place a phone call to this person.” does not.

Do not say the name or type of the GUI element. Avoid hints that refer to the UI item being manipulated. Skip the GUI name (its label, such as “Delete”) and type (its class, such as “button”). VoiceOver adds that information where needed, preventing any overly redundant playback, such as the confusing “Delete button [label] button [VoiceOver description] button [hint] removes item from screen.” Use the succinct “Removes item from screen.” instead.

Avoid the action. Do not describe the action that the user takes. Do not say “Swiping places a phone call to this person” or “Tapping places a phone call to this person.” VoiceOver uses its own set of gestures to activate GUI elements. Never refer to gestures directly.

Be verbose. “Places call” does not describe the outcome as well as “Places a call to this person,” or, even better, “Places a call to John Smith.” A short but thorough explanation better helps the user than one that is so terse that the user has to guess about details. Avoid hints that require the user to listen again before proceeding.

Localize. As with labels, localizing your accessibility hints works with the widest user base.

Testing with the Simulator

The iOS simulator’s Accessibility Inspector is designed for testing accessible applications before deploying them to the iOS device. The simulator’s inspector simulates VoiceOver interaction with your application, providing immediate visual feedback via a floating pane (there is no actual voice produced) without requiring the use of the VoiceOver gesture interface directly. Because you cannot replicate many VoiceOver gestures with the simulator (such as triple-swipes and sequential hold-then-tap gestures), the inspector focuses on describing interface items rather than responding to VoiceOver gestures.

Enable this feature by opening Settings > General > Accessibility. Switch the Accessibility Inspector to On. The inspector, shown in Figure 15-2, immediately appears. It lists the current settings for the currently selected accessible element.

Figure 15-2 The iPad simulator’s Accessibility Inspector highlights the currently selected GUI feature, revealing its label, hint, and other accessibility properties.