Apple’s iOS Human Interface Guidelines encourage developers to create compelling, immersive mobile interfaces. The goal is to delight the user with an inventive interface that invites the user to touch and explore. Often times, this leads to designs with interactions that are not immediately understood.
Many apps will use graphic icons to suggest available functionality. Unfortunately, these icons are not always made accessible to VoiceOver users. Other interactions take advantage of the natural reactions to swipe and pull on items. As VoiceOver users tend to explore by dragging their finger over the screen or using a single finger swipe to “tab” through the page, these interactions may not be discovered.
For instance, a list of items may be refreshed by pulling down, a button may list a selection title and provide a drop down to select an alternate, images can be scrolled, and text can be tapped to trigger playing music.
Fortunately iOS provides a convenient solution: accessibilityHint. Ron Nicholson described UIAccessibiltyHint usage in his company’s iPhone apps:
If you had a short help document for your app, it might show a picture of your app, with arrows pointing at the elements, and a small bubble caption on each of those arrows saying stuff like "Stops playing annoying fart sounds" and "Changes fart loudness from silent to ear shatteringly gross". These would be your helpful "hints".
iOS accessibility: label vs hint – Stack Overflow
Developers need to carefully consider when an accessibilityHint is needed. Further, the hint should be short, declare the purpose, and not mention the gesture or type of object the user is interacting with. Apple’s Accessibility Programming Guide suggests using a hint “only when the results of an action are not obvious from the element’s label”. Matt Gemmell summarizes the art of creating good hints:
A good accessibility hint should describe the outcome of interacting with the control. It should not describe the actual means of interaction (like tapping or swiping), because there are multiple ways for a VoiceOver user to interact with your control, and you can’t predict which they’ll use. Hints should begin with a plural verb, if at all possible; for example, “Deletes the event”. Do not use a singular verb (such as “Delete the event”), because this will sound like an imperative (a command or instruction to the user).
Accessibility for iPhone and iPad apps – Matt Gemmell
The following iPhone applications use accessibilityHint effectively.
Hanging with Friends – Zynga
Hanging with Friends provides updates on other games you are playing. The button’s label includes the game’s name: “Play Words”. The button’s accessibilityHint lets you know it will either switch applications or install the game: “Switches to or intalls the game Words.”.
Yahoo! Search for iPhone
The Yahoo! Search app has a scrolling view to choose various categories. While there are arrow icons that prompt the user to swipe for more options, they’ve also added accessibilityHint. In this case, the developers included the swipe action to make sure users know how to navigate. The accessibilityHint is “Swipe to get more categories.”.
Yahoo! Finance for iPhone
The Major Indices table on the Yahoo! Finance app lists the vaue and price on markets and stocks. The individual cells have an accessibilityLabel that compiles the displayed information into a useful string of text: “Nasdaq 3,065.27 down 13.05 or 0.42%”. The accessibilityHint lets the user know they will find more information about this market: “Displays more details.”.
Implementing the accessibilityHint
There are several options for adding an accessibilityHint via Interface Builder or in the .m file.
Using Interface Builder
The accessibility panel is located within the Identity Inspector column of XCode. This panel lets you set the various accessibility traits of objects inserted within the .xib or .storyboard files. This works best for static hints.
Apple’s sample app Formulaic has a button with Label="Show table". We can add an accessibilityHint to let the user know the table will display the results of the equation: Hint="View equation results in tabular format.".
Inserting at viewDidLoad
Many developers will add accessibility attributes at the viewDidLoad stage. viewDidLoad is called after instantiation and outlet-setting, . Paul Hegarty explains this is "an exceptionally good place to put a lot of setup code" in his discussion of view life cycles (Stanford iTunesU: iPad and iPhone Application Development – Lecture 8). The previously mentioned Formulaic app sets an accessibilityHint on the stopwatch button at this stage.
// update the graph view
// set the hint for the stop watch button
// allow updates of graph
shouldUpdateGraph = YES;
Set accessibilityHint at Initialization
Another option for adding an accessibilityHint is during initialization of an object. This example comes from a lecture given by Chris Fleizach, also available on Stanford University’s iTunesU – Developing Apps for iOS 2010 (look for lecture #18).
bowlingBall = [[BowlingBall alloc] initWithFrame:CGRectZero];
bowlingBall.accessibilityLabel = NSLocalizedString(@"ball.label", nil);
bowlingBall.accessibilityHint = NSLocalizedString(@"ball.hint", nil);
This code also shows how you can localize your labels and hints using NSLocalizedString.
The majority of iOS apps can easily be made accessible by using a combination of accessibility attributes. Accessibility hints avoid vague interactions and make the application easier to understand and navigate. For more information, visit the following resources:
- Accessibility Programming Guide for iOS
- Formulaic – accessible app tutorial from Apple
- UIAccessibility Protocol Reference
- UIAccessibilityElement Class reference
- How TipToe was fixed
Please note: Some of the links in this article require an Apple ID or lead to pages that will trigger iTunes.