iOS accessibility: A brief introduction

May 4, 2016

This is a guide for any dev that wants a kickstart into learning the iOS Accessibility APIs. Fortunately, the accessibility frameworks on iOS are very compact and Apple has built in a lot of sane defaults into the views and controls of iOS. While all the standard UIKit components tend to work out of the box you will usually need to configure your custom view elements to make your app really shine for accessibility users.

What is accessibility?

Accessibility means making apps usable for everyone. Including those who need assistance with or are limited in:

  • Vision
  • Hearing
  • Physical & Fine motor movements
  • Learning and Literacy

Accessibility for iOS developers for the most part means exposing their apps to VoiceOver, Apple’s screen-reading technology.

Working with VoiceOver means providing the information it needs so it can communicate to the user. It is important to be aware that supporting accessibility does not impact your ability to innovate and create beautiful iPhone applications. The UI Accessibility programming interface allows you to add a thin layer of functionality that does not alter your application’s appearance, or interfere with its main logic.

The basics

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.

Configuring Accessibility of Individual Views

An accessible view can be configured by setting one or more of the below attributes. VoiceOver reads out a combination of the below attributes. Usually in the form of <accessibilityLabel><accessibilityValue><accessibilityTraits><accessibilityHint>.

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.”

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.

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

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

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%”.

Note that:

  • An element that does not perform an action doesn’t need to provide a hint.
  • A static element does not need to provide a value.
  • Many of these attributes have very sane defaults derived from UIView, UIControl etc.
  • Standard UIKit controls and views are automatically accessible.
    • However, you should also make sure that their attributes make sense e.g. appropriate hints and labels.

Configuring accessibility of custom container views

If your application displays a custom view that contains other elements with which users interact, you need to make the contained elements separately accessible. At the same time, you need to make sure that the container view itself is not accessible. The reason is that users interact with the contents of the container, not with the container itself.

In most cases the default implementation for a UIView will work but when it doesn’t your custom container view should implement the UIAccessibilityContainer protocol. This protocol defines methods or a property that make the contained elements available in an array.

Since iOS 8 the simplest way to implement this looks like:


- (BOOL)isAccessibilityElement
   return NO;
- (NSArray *)accessiblityElements
   return @[view1, view2, view3];


Our tips

We’ve developed several apps that had accessibility requirements. It didn’t always go smoothly, here are some of the things that we have learnt.

1) For developers, implement accessibility as a part of your main development cycle and not at the end of a project. This will allow you to tweak UI design to fix any accessibility issues as they arise.

2) During estimation, take into account time to implement accessibility. In our experience, implementing accessibility usually takes 10-25% over the dev effort. For non-standard components, it might be more expensive.

3) Set the accessibilityTrait of a custom view – Accessibility traits that tell an assistive application how an accessibility element behaves or should be treated. For example, if a tapping on a UIView caused the app to transition to another view, then we must set the accessibilityTrait on that view to be UIAccessibilityTraitLink. This means that VoiceOver would indicate to the accessibility user that the view they are focused on is a link and double tapping it would lead them somewhere.

4) Use the accessibilityTrait and accessibilityLabel to succinctly explain what the current element is and does. Use accessibilityHints sparingly, some accessibility power users save time by turning off accessibility hints and relying more on the trait to tell them how to use the app.

5) If your view is dynamic and changes frequently, you must post an UIAccessibilityNotification telling VoiceOver that something has changed. See here for various types of UIAccessibilityNotifications that you can post. For example: You may post an UIAccessibilityLayoutChangedNotification when the layout of a screen changes, such as when an element appears or disappears.

6) For UX designers, keep accessibility in mind while designing an app. Use of non-standard UI controls might pose a problem in accessibility mode. So it might be a good idea to involve devs in the design process.

For example: We have a semi-circular slider in an app that lets the customer input an amount. The value of the amount can range from $25,000 to $1,500,000. The trait for this control was initially set to be UIAccessibilityTraitAdjustable. This meant that the value of the view can be adjusted by swiping up or down. But if swiping up/down adjusted the value in steps of $5,000 the customer would have to swipe 295 times to get from min value to max value! This is terrible UX.

The only feasible solution was to have the control behave differently in accessibility mode. When accessibility is running, we set the view’s trait to be UIAccessibilityTraitButton. On tapping the view we pop up an alert with a text field that takes the amount.


In conclusion, making your app accessible takes a bit of effort and time, especially if it’s an add-on to an existing project, rather than being added as you develop your app. It’s another thing to take into account while creating your app. However, adding accessibility is well worth it. It means your app can reach more people and possibly change their daily life.



Author: Tristan Burnside, iOS Developer

iOs accessibility image