How to Build Accessible iOS Apps

These notes were created by Donald Burr of Otaku No Podcast from otakunopodcast.com. Donald was the guest on episode #364 of the podcast. If you’d like to listen to the audio as you read along, click the link below:

Donald Burr on Accessible App Development

How to Build Accessible iOS Apps by Donald Burr

When the iPhone first came out, people assumed that the blind wouldn’t be able to use it because it’s a touchscreen device with only 4 buttons. Apple proved them wrong. They have embraced accessibility in a BIG way. The iOS platform is the industry leader in mobile accessibility. Android, Windows Mobile, Blackberry, etc. don’t even come close. That’s why I’m a Mac/iOS user – my vision has fortunately remained stable, but I am always afraid that things might take a turn for the worse… but if they do I am ready for it

When talking accessibility, what are we talking about?

Primarily will be talking about accessibility for the visually impaired, because that’s the one that requires the most effort from developers. There are some considerations for other disabilities which I will briefly touch on later.

Basically each thingie on screen (button, text field, label, icon, etc.) has certain attributes that the Accessbility API’s need:

• Is it an accessibility element? (Should VoiceOver be able to “see” it and recognize its existence?) (isAccessibilityElement)
• What is it? (accessibilityLabeland accessibilityHint)
• What are its traits? (accessibilityTraits)

• Type of item (static text, button, image, adjustable control, etc.)
• Is it clickable (can you interact with it)?
• If it’s a selectable object, is it currently selected?
• Does clicking on it start some sort of media playback (audio/video)?

If it’s an adjustable control, what is its current value? (accessibilityValue)

What are its on-screen coordinates? How big is it? (accessibilityFrame)

Here’s the good news: Apple makes it really easy to make your apps accessible. They provide a very rich set of tools and APIs that help with this. Which means you have absolutely positively NO excuse not to! In most cases, all it invokes is literally just a few extra lines of code, and poof, instant accessibility. In some cases, no coding is required at all.

Standard UI elements:

• One of the great things about developing for iOS is Interface Builder – you can piece together your program’s UI by dragging and dropping from a large palette of UI widgets (text labels, buttons, sliders, etc.)
• If you use these standard interface elements – guess what – the system automatically makes them accessible. Since Interface Builder knows what it is you’re putting on screen, it automatically fills in the necessary accessibility information.
• Works best if your UI has obviously titled elements (i.e. a button titled “Play” that starts playing something).
• Beware ambiguous labels (or controls that don’t have a label)!

• Example: In the Otaku no Podcast app, in the Podcasts screen (first tab), there are entries for “Latest Audio Podcast” and “Latest Video Podcast.” Beside each is a “Play” button. It’s obvious to a sighted user what each Play button does; however, for a VoiceOver user, all they would hear if they tapped it is “Play” — play what??!
• Example 2: In the Otaku no Podcast app, look at the Audio Player screen. The “play button” at the lower left uses the “play” graphic – no text label. In this case, since VoiceOver doesn’t have a text label to fall back on, it uses the filename of the image that the button is using. So you’ll hear something like “playbtn dot PNG” which is even worse!
• In cases like this, we need to give iOS some more specific information.
• In Xcode, highlight your UI element, then go to the Identity Inspector. There you will find a section on “Accessibility.”
• “Enabled” – whether this item should respond to VoiceOver (You’ll almost always want this)
• “Label” – What you want it to say (Example: for the “Audio Podcast -> Play” button I put “Play the latest audio podcast”; for the “play graphic” button I put “Play”)
• “Hint” – This text is spoken after a short delay after the “label” is spoken. Useful to give the user additional information about this particular UI element. (Example: for the Refresh button, the button’s Label is “Refresh”, and its Hint is “Tap to check for new episodes…” – it gives the user some additional information if he/she is confused.)
• “Traits” – Most of these options are very specialized, and you don’t want to go turning them on willy-nilly. Here are the important ones:

• “Button” – is this a button?
• “User interaction enabled” – can you “do” something with it? (I.e. tap a button, enter text into a text field, etc.)

You can still manipulate these values in code if you want (handy if e.g. you need to change your UI to respond to conditions when your app is running).

Some actual examples from the Otaku no Podcast app: https://www.dropbox.com/gallery/169813/1/iOS%20Accessibility?h=1f050c
Look at “OnP main screen – play latest button,” “OnP main screen – refresh button,” and “OnP player screen – graphical play button”

Custom UI elements

• Sometimes the standard controls aren’t enough (you need more/different functionality); also sometimes you may use standard controls, but want to create and manipulate them in code (rather than using Interface Builder). In these cases, you will need to use code to set up all the necessary accessibility information.
• All accessibility information can be set in code.
• Example:https://www.dropbox.com/gallery/169813/1/iOS%20Accessibility?h=1f050c
  Look at “adding to code 1” and “adding to code 2”

Accessibility Containers

• Sometimes you may have an object that is subdivided into multiple sub-objects. You need to provide accessibility information for those sub-objects.
• Example: the Convention Calendar tab in the Otaku no Podcast app. The entire calendar view is a single object; each individual day is a sub-object. Unfortunately this is one area where I still need work; it is completely inaccessible. I’m using an open source calendar library that isn’t yet accessible. I’m working with the developer to add accessibility to it. For an example of this done right, take a look at the iPhone’s Calendar app, in Month view.
• In this case, we use a series of “accessibility containers.”
• Each container provides a full set of accessibility information to the OS (description/label, value, hint, etc.), as well as the bounds (the physical location/dimensions of the area where this accessibility information is attached to).
• These elements are stored in an array (an ordered collection of objects). You need to provide three pieces of information to the Accessibility API’s: the number of items in this array, a way of retrieving a given item #, and a way of testing if a given item is part of the array. (In 99% of the cases, these will be trivial one-liners.)
• Example:https://www.dropbox.com/gallery/169813/1/iOS%20Accessibility?h=1f050c
  Look at “container code 1” and “container code 2”
  Another good (more real life) example can be found in the Use Your Loaf TaskTimer project (see below); look at theUYLCounterView.m file

Accessibility Actions

• If you are creating a custom adjustable control, you need to give VoiceOver information on how to manipulate its value.
• VoiceOver has two standard gestures: swipe up (increases the value of something) or swipe down (decreases it).
• So when coding your custom control, you need to create special “increment” and “decrement” code that VoiceOver can use to change its value.
• A good example of this is the page turner in iBooks (the little dotted line with the box at the bottom that lets you quickly page through a book).
• A third type of gesture is “scroll.” This is meant for a control that scrolls to a different part of your UI. Example: moving between home screens, or scrolling between cities in the Weather app.
• Example:https://www.dropbox.com/gallery/169813/1/iOS%20Accessibility?h=1f050c
  Look at “action code 1” and “action code 2”

UI Changes

• The iOS user interface is very dynamic. Things are moving around, morphing, swooping in and out, etc. Obviously blind users can’t see this. So iOS provides a way for developers to let the user know that “something happened” using VoiceOver.
• There are three types of UI change notifications.
• Screen changes: when your UI changes dramatically. Usually when a user moves into a different part of your app (navigates to a different screen). VoiceOver notifies the user with a tone, and it clears its caches and does other preparations to deal with a new set of accessibility data.

• UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, nil);

Layout changes: if some part of your UI changes, but the user hasn’t necessarily jumped to an entirely different part of your app. (Example: in the iTunes Store app, tapping on the price label ($0.99, etc.) next to a song changes it to a “Buy” button.) This notification tells VoiceOver to re-read the current state of all accessible items that are on-screen, and by doing this it figures out what has changed and informs the user of those changes.

• UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, nil);

Dynamic changes: if a part of your user interface is dealing with some dynamically changing information (state changes, data changes, etc.). This notification tells VoiceOver to read it out to the user. Example: in the Compass app, the compass value is constantly changing as the user moves his/her device in space. The Compass app sends a dynamic changes notification that tells VoiceOver to read out your current heading. Also useful for communicating any sort of significant status change in your app (“Loading complete,” “Connected to server,” etc.) You may only want to do this when a significant change in data has occurred, otherwise it can get real annoying. (for example, Compass only notifies when the compass value has changed by 5 degrees I believe.)

• UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification, @”Loading complete.”);

VoiceOver-specific API

• Sometimes it is useful to determine whether or not VoiceOver is running, and to do different things depending on whether it is or not.
• A program can, at any time, test to see whether VoiceOver is enabled or not.

• if (UIAccessibilityIsVoiceOverRunning()) {
  // VoiceOver is active; do something different
  }else {
  // VoiceOver is NOT active; do the usual thing (whatever that may be)
  }

Also, programs can sign up for the system to notify them whenever the VoiceOver status changes.

• [[NSNotificationCenter defaultCenter]addObserver:self selector:@selector(handleVoiceOverStateChange:) name:UIAccessibilityVoiceOverStatusChanged object:nil];

Your program can also tell where VoiceOver’s “focus” (the object that it’s dealing with) is, and when “focus” enters or leaves any given object.

• accessibilityElementIsFocused
• accessibilityElementDidBecomeFocused
• accessibilityElementDidLoseFocus

A good use for this is, when a user is running VoiceOver, to present a more simplified UI to them, or otherwise change your UI to make it easier for VoiceOver users to interact with. Example: In the Photos app, the photo controls normally disappear after a few seconds to let you view the full image. This could be confusing to VoiceOver users; so if Photos detects that VoiceOver is in use, it prevents this auto-hiding behavior.

Miscellany

• If you localize your app, you also need to localize your VoiceOver prompts! (VoiceOver is available in 30 languages)

• If you’re not localizing, you really ought to. The App Store is global, why shut out a potentially huge user base? Getting translators is easy and relatively inexpensive (try Craigslist).
• Remember that localization doesn’t just mean translating words and letters; some countries have different ways of expressing date/time, currency, etc. iOS has code that helps in these conversions.

It’s always good to think outside the box.

• With clever use of the accessibility tools, you can make things accessible that you wouldn’t think were possible.
• A good example is the Stocks app. You’d think that there is no way that the graph at the bottom could be made accessible. You would be wrong.
• They used accessibility areas to slice up the graph. For each slice, it tells you a representative date within that period, and the stock price for that date.

Less is more.

• Keep your labels short. Users are going to be scrolling through these dozens of times.

• If you want to provide additional information, use an accessibility hint. (That way users only get the additional information if they actually need it)

The more buttons, interactive elements, etc. on a screen, the harder it is for a VoiceOver user to navigate it.

• If you really want the fancy UI, check to see if VoiceOver is in use; if it is then present a simplified UI.

Do not include an object’s type (“button,” “slider,” etc.) in its accessibility label. iOS will automatically read out the item’s type itself, so there’s no need for you to do so also (besides it makes your app look amateurish).

Remember that there are other disabilities besides blindness.

• Physical Disabilities:Try not to make your UI teeny tiny. Of course this makes it more difficult for sighted people to use your app. But it becomes orders of magnitude worse when you throw physical disabilities into the mix(motor control difficulties, CP/MS, or people who use a head-mounted pointer, etc.) It also makes it harder for visually impaired (but not completely blind) users to see your app as well. IMHO this might be a compelling argument for a larger-screened iPhone (more space to spread out your UI in).
• Deaf/Hard of Hearing: Some programs use sounds to indicate that something happened. It’s always a good idea to also include some sort of visual feedback as well, for those who are deaf/HOH.

Use standard controls (text entry fields, buttons, etc.) whenever possible. Not only is this good for usability (users know what an iOS text box/button/on-screen keyboard/etc. look like, they may not be able to instantly recognize your weird nonstandard UI); but using standard UI elements also gives you the highest level of compatibility with alternative input devices (head pointers,braille displays/keyboards, etc.). (Bad example of this is Mac OS Ken’s Secret Crypto Wonder Badge. Totally nonstandard keyboard.)

Resources

• Apple’s Worldwide Developers Conference (WWDC)
  Conference info and registration: https://developer.apple.com/wwdc/
  Videos of all conference sessions (2010 and 2011’s are up now, 2012’s will be up a few weeks after the conference is over): https://developer.apple.com/videos/
  Note: conference videos are now available even to free developer program members!
  If you’re a serious developer, you need to go to WWDC. Unfortunately it tends to sell out pretty fast, so you’ve gotta be quick! They do make all conference videos available to paid developer program members; however, the real benefit of attending WWDC is that you get one-on-one “face time” (f you’ll pardon the pun) with real live Apple engineers who help you with your coding issues and help make your apps better.
• Apple’s iOS Accessibility Programming Guide:http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/iPhoneAccessibility/Accessibility_on_iPhone/Accessibility_on_iPhone.html
• Stanford CS193P iOS programming course on iTunes U:http://itunes.apple.com/us/course/ipad-iphone-app-development/id495052415
• CS193P Accessibility lecture:http://www.youtube.com/watch?v=5b0V6MltEnw
  Slides from this lecture: Accessibility.pdf
  In the past the CS193P course has had a lecture on accessibility; for some reason they didn’t in this year’s iteration of the course. Fortunately a video of the previous year’s accessibility lecture is still on YouTube. In this lecture the speaker gives a good overview of the accessibility API’s. He also does a demonstration in which he takes a completely inaccessible app (a bowling game), and in a few simple steps, makes it completely accessible and playable by even completely blind users.
• “Smartphones Become Essential Accessories for the Blind”:http://www.youtube.com/watch?v=NQKtSR5Li1A
  This video was shown during the Stanford class above. It is a great overview of how the iPhone is really revolutionizing the way blind and visually impaired people interact and function in their daily lives.
• VoiceOver article at Use Your Loaf: http://useyourloaf.com/blog/2012/4/23/voiceover-accessibility.html
  Another good overview of iOS accessibility (basically what we covered here). He has also provided a downloadable Xcode project with working code samples illustrating all of the various methods of adding accessibility to an app; developers should definitely should download that and take a look.
• My screenshots, pictures, etc.: https://www.dropbox.com/gallery/169813/1/iOS%20Accessibility?h=1f050c

The obligatory plugs section

• Check out my iOS apps!

• Otaku no Podcast (free): http://otakunopodcast.com/app/
• SongTweeter (free): http://SongTweeterApp.com/
• NerdTool ($1.99): http://NerdToolApp.com/

My portal site – links to everything I do, as well as houses my blog. http://DonaldBurr.com/

I’m on twitter as http://twitter.com/dburr/

And finally, if you are at all interested in Japanese animation (Anime), comics (Manga), food, travel, culture, etc., check out my podcast, Otaku no Podcast. http://otakunopodcast.com/