Starting accessibility with iOS

Why accessibility matters

The smartphone is an amazing device, it lets us find and consume almost any information we could want and communicate with anyone around the world in text, speech or video. By being this versatile the smartphone has become a central part of many people’s lives. I use my smartphone everyday and take all of its features for granted.

So what would happen if I lost my phone? I would probably get a new one or start using the older one I keep lying around as a backup. So losing my phone is no big deal really, might hurt financially but that is it. What if I lose my eyesight as I grow older or have an accident?

Not being able to use a smartphone would be a big limitation on what I could do and how I would do things.

Having a disability is sadly a reality for many people and not trying to make your application as accessible as it could be is a bad choice for two main reasons. Firstly it is not good for business to not serve this huge market of potential customers and secondly it is the right thing to do.

Check your application

The best way to test the accessibility of your application is to let a visually impaired person test it. As this is a luxury you probably do not have you can compensate by just closing your eyes and trying to use your application.

This is very time consuming so it should be treated more as an acceptance test. What you should use during development is the Accessibility Inspector that comes with Xcode.

Accessibility Inspector

To open the Accessibility Inspector select Xcode → Open Developer Tools → Accessibility Inspector in the tool bar. Accessibility Inspector has three main views that you can interact with Inspection, Audit, and Settings. To the left you choose which process you want to inspect and for iOS projects you will always choose the simulator here. The button in the middle turns the inspection on and off.

Accessibility Inspector

Inspection: Here you will find accessibility data of the currently selected view. It is a quick and easy way to confirm that controls and text have the correct labels and values.

Audit: Instead of inspecting and looking at everything one by one you can do an audit of the current screen and get warnings if something seems to not meet Apple’s standards. It will also give you advice on how to fix these warnings. Just remember that it will only audit the currently showing screen so you will need to traverse all of the application’s screens.

Settings: Here you can change the most common accessibility settings (invert colors, reduce transparency, reduce motion, and increase font size) on the fly for the simulator. This is great as increasing the font size is very popular and this is an easy way to make sure that your application can handle this.

Where to start

Luckily it is very easy to implement accessibility features in your iOS application. If you are using standard components and have reasonable text in your button labels you may not have to do anything at all. But most of the time that is not the case and you will need to spend a little time.

So let’s say that we have a button that has an image and no text in its label. The button design is a + that represents adding an item to a list. The problem here is that the accessibility label will grab its text from the image of the button. This a problem as the image is not very likely to have a describing name of what that button is.

So what needs to be done here is to explicitly set what text should be used when the system asks for this button’s accessibility label. This is easiest done by going to the Identity Inspector. Here you will find an editor for some of the available accessibility attributes you can set.

Identity Inspector

Identity inspector accessibility

Accessibility: Tell the system if the element has accessibility information. Not all elements in a user interface need to be accessible. As with a every user interface it is important not to clutter it with unnecessary noise.

Label: Describe the control/view. Keep it short to not annoy your user. Examples: New game or Add date.

Hint: Say the outcome of the action. It should not repeat any information given by the label or trait. Example: Adds date to the event.

Identifier: This is only used in UI testing so it can be ignored for accessibility.

Trait: Describe the control’s state, behaviour, or usage.

The last touch

If you have been a responsible iOS citizen and filled in the labels and hints your application should probably meet the standard for accessibility but if you have dynamic elements or non-textual data there is just a little more to do.

Dynamic elements

A dynamic element is an element that will have a different behaviour depending on some state. If one button is pressed somewhere and something else happens in the layout because of that change it is important to signal that change to the user. You tell the system this information by posting a notification with the UIAccessibilityPostNotification function and telling it what changed and some context to what happened.

class PlaceView: UIView {
  var location = "Home" {
    didSet {
      UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, "Place view changed")
    }
  }
}

Non-textual data

Sometimes you may want to convey information to the user in a graphical way. It may be an image or a view that changes depending on some state. A solution to this is to implement/override the property accessibilityLabel and make it a computed property.

class PlaceView: UIView {
  var location = "Home"

  override var accessibilityLabel: String? {
    get {
      return "\(self.accessibilityLabel) \(location)"
    }
    set {
      self.accessibilityLabel = newValue
    }
  }
}

Conclusion

That is all there is to it if want your application to be usable by people with visual impairment. I hope this showed you how easy it is to test and improve accessibility in your application. There is of course more to learn and do that I did not go through here but this will give you a solid start.

Learn more

If you want to know more I highly recommend this blog post by Matt Gemmell (it is a bit dated but I think almost everything is still applicable) and this blog post about accessibility by Robin here at Varvet.