Exploring accessibility

Find out how to examine accessibility information in your app using Reveal

Making your app accessible for the visually impaired is not only a good service to humanity, but also brings the quality and attention to detail of your product to the next level.

UIKit provides great support for implementing accessibility and Reveal makes it easy to debug by allowing you to inspect this information at runtime.

The Identity Inspector

The Identity Inspector displays a host of information related to the selected view including the restoration identifier, class, memory address, and the associated View Controller.

It also displays a number of properties from the UIAccessibility protocol that you might find useful when making your application accessible or when writing automated tests.

Pro Tip: Although some of the properties are editable, changes made through the Identity Inspector may not persist if the view has implemented the UIAccessibility protocol methods to return hard-coded values.

Let’s have a look at the accessibility information displayed in the Identity Inspector


Indicates whether the view has accessibility enabled and responds to user interaction. If the view doesn’t have accessibility enabled then VoiceOver won’t read it to the user, nor allow interaction with it by double-tapping.

According to the Apple documentation, the only use case to not set this to true is: “[…] a view that merely serves as a container for other items that should be accessible. Such a view should implement the UIAccessibilityContainer protocol and set this property to NO.

Corresponds to isAccessibilityElement. Pro Tip: when you hover over an inspector field name a tooltip will display the corresponding UIKit property name.

Should Group Children

By default VoiceOver, Apple’s gesture based screen reader, will scan and read the UI left to right, top to bottom, regardless of the subviews hierarchy. This default mode might not be the best way to present certain kinds of content. Information could be organised in columns, for example, and the best way to read it would be column after column. In such cases setting the value of shouldGroupAccessibilityChildren to true will make VoiceOver group together the elements in the receiver, and read all of them before moving to the next element in the normal order.

In the example above the container views are not set to group their children, and VoiceOver will read “1, 3, 2, 4”.

With shouldGroupAccessibilityChildren set to true VoiceOver will read “1, 2, 3, 4” as intended.

Note that if we had implemented the layout above using two instances of UICollectionView we would have had the desired VoiceOver behaviour out of the box.


Corresponds to the accessibilityTraits property and contains a mask that best characterizes the accessibility element, giving VoiceOver the context needed to read it properly.

Activation Point

The activation point of a view is the point, expressed in screen coordinates, to which VoiceOver will send a touch event when the view is double-tapped.

Corresponds to the accessibilityActivationPoint property.


The frame of the accessibility element, in screen coordinates, as set in the accessibilityFrame property.

All UIView subclasses have this value set for them automatically but the value can be altered by overriding accessibilityFrame in a subclass.

Pro Tip: don’t confuse this property with the frame of the view. It is set in screen coordinates and may not necessarily map to the position of the view’s frame.


The accessibilityLabel property is a short, localized label that succinctly identifies the element.


The default value for this property is nil unless the receiver is a UIControl subclass. In this case it represents the value of the control as a localized string if it differs from the label.


For interactive elements the accessibility hint provides a way to briefly describe the expected result of the user interacting with the element.

It corresponds to the accessibilityHint property.


Unlike the rest of the accessibility information in the Identity Inspector, the identifier is not part of the UIAccessibility protocol. It corresponds to the accessibilityIdentifier property of the UIAccessibilityIdentification protocol.

This value is meant to be used to uniquely identify views in the context of UI tests, and is never read by VoiceOver.


The language in which to speak the accessibility element’s label, value, and hint. Most of the time this field will be empty since nil is the default value and correspond to the user’s current language settings.

View is Modal

This value, corresponding to accessibilityViewIsModal, represents whether VoiceOver should ignore the elements within views that are siblings of the receiver.

This can be useful when displaying custom views that are presented modally.

Elements Hidden

This value, corresponding to accessibilityElementsHidden, represents whether the accessibility elements contained within the view should be ignored by VoiceOver.

Apple’s documentation states “you might also use this property to hide a transient view that VoiceOver users don’t need to notice. For example, VoiceOver doesn’t need to describe the translucent view that appears when users adjust the volume on their devices, because the aural feedback of this action is sufficient.”

Pro Tip: Turn on the Accessibility Inspector

Sometimes you might not see all the expected accessibility information appear in the Identity Inspector. This can happen because the information is only vended by the iOS application once the classes that implement accessibility have been dynamically loaded at runtime. You can see proof of this by looking at the Xcode 7 UI test execution output. Before any interaction starts the test runner says Waiting for accessibility to load.

To enable accessibility in the simulator you need to turn on the Accessibility Inspector.

  1. Go to the Settings app. You can background a running app by pressing Cmd + H, which simulates pressing on the Home button.
  2. Select the General options.
  3. Select Accessibility.
  4. Turn the Accessibility Inspector switch on.
  5. You should now see the Accessibility Inspector window and the accessibility information for applications you inspect with Reveal should now be visible in the Identity Inspector.

While we have shown how Reveal can help inspect the accessibility properties of your views, we’d love to hear how you’re using these features when it comes to implementing accessibility and writing automated tests. You can tweet us @reveal_app or email us your feedback.