iOS Development

Little tricks of Accessibility

When I code, in my mind’s eye I always seem to imagine the user who is looking at or using the feature I am developing. It helps me look at my work from a more consumer driven perspective. A piece of feature, though seems not worth the time and effort, may seem indispensable from that perspective. Such a different perspective becomes of paramount importance when thinking of extending your application’s reach to people who are deprived of experiencing the world the same way as we do.
The importance of providing accessibility for differently abled people to your application can not be emphasised enough. Yes, it is extra hassle. Yes, Apple will still accept your app even if you don’t implement accessibility. And yes! the people who need accessibility are very little compared to the the large user base you are going to cater to. But — it is the right thing to do, it can change someone’s life and for your part: you may be subject to millions of silent tearful thanks and blessings from all over the world for changing so many lives in a better way. If all these do not bother you, close your eyes (imagine you are blind or nearly so) and try to access your computer, you will be bothered.

So, when it is such a great thing to do, why most of the applications don’t offer accessibility support? Why most of the applications downloaded straight from App Store just become unusable in accessibility mode? I believe what discourages people to go this extra mile is the nasty little problems that pop in when you start making your app accessible. Despite such great articles by Matt Gemmell and Mattt Thompson and other readily available examples, there are so many unique problems that arise when implementing accessibility that it really puts off the developer unless she is really a motivated person to implement it. This article ventures to dust away those nasty little problems faced by any iOS accessibility developer as much as possible.

Define: Accessibility

Accessibility is the degree to which a product, device, service, or environment is available to as many people as possible. Accessibility can be viewed as the “ability to access” and benefit from some system or entity. The concept often focuses on people with disabilities or special needs (such as the Convention on the Rights of Persons with Disabilities) and their right of access, enabling the use of assistive technology.

So what is this all about? If you have never used the iOS devices in accessibility mode it’s of utmost important for you to do it now before we move on to more complicated details:

  • Open the Settings App
  • Go to General –> Accessibility
  • Turn On the Voice Over switch

As you do that, suddenly you will find yourself in a rather inaccessible situation where none of your usual touches and gestures will behave the same way it did normally. Well, don’t fret mon ami, here are the rules of this world to get you started:

  • Tap once to select an item
  • Double-Tap to activate the selected item
  • Swipe with three fingers to scroll

Also, if you do a single finger swipe, the focus of the voice over will shift from one element to another sequentially. When you will be testing accessibility in the device, you will need to quickly switch ON and OFF this mode and there is a shortcut with which you can do that:
In the Settings app —

  • Go to General → Accessibility and
  • Scroll down to the bottom of the screen and tap on the button “Accessibility Shortcut”
  • And check the “Voice Over” option from the next screen
  • Now, triple press the Home button of the iOS device — VoiceOver turns on. At any point of time, you can triple press the Home button to turn it off.

The accessibility can also be tested in iPhone Simulators and the accessibility inspector can be enabled in the “Settings” app in the simulator.

Is it hard to implement?

Despite of the fact that there are several great articles which offer interesting insight into Accessibility on iOS devices, they often seem to oversimplify the hassle of implementing VoiceOver and other accessibility methods, I guess, to liberate you of the fear of  going the extra mile to implement accessibility. Honestly, they are partially true. Here is a quote from Matt Gemmell’s blog which is arguably the best accessibility article existing on the web. he says as below:

The good news is that it’s incredibly easy to add accessibility support to your application (there’s no bad news, incidentally). The reality of adding accessibility support to your app is that:

  1. About 80% of your app is probably accessible already, via the built-in VoiceOver support in UIKit.
  2. You can probably boost that to around 95% simply by spending a few minutes in Interface Builder, without writing a single line of code.
  3. And you can very likely reach 100% accessibility support via implementing some incredibly trivial methods, which will also take you just a few minutes.

Well, not so fast.

For a complex enterprise level application which offers accessibility, making the application compliant to the Disability Discrimination Act and similar ones may become a project in itself. But, no, it is definitely not rocket science. It just demands a little determination, clarity of thought and industry. So, what holds you up? As I told you before, the nasty little problems. What are they?


Background items are visible.

Accessibility has a bad habit of revealing what’s underneath the curtain. Technically, that means when you add a subview over a view and there are elements that are under your new view, they also get focussed and announced

for (UIView *view in [self.view subviews]){
[view setAccessibilityElementsHidden:YES];

There are 2 methods that can be called on a view to render that particular view element inaccessible:

  • isAccessibleElement
  • setAccessibilityElementsHidden

The good thing about the later one is that when it hides one element, it hides the subviews too. This can prove really helpful in the scenario where you have a got a pretty deep view hierarchy.

The single finger swipe is not selecting items on the screen in order

Well, this can prove to be a real nasty one sometimes, because the accessibility switches its focus in the sequence in which the views are laid out in the interface builder and it is not always possible to alter the hierarchy. Apple has suggested a really great and powerful approach. Follow the below steps to dodge the bullet:

  1. Create a subclass of UIView and assign that class to your view in the Interface Builder
  2. In the subclass, over ride the accessibleElements setter
  3. Add the elements of your choice in your preferred order in the array and return it
  4. Implement the UIAccessibilityContainer protocol methods

So, the code sums up to the following (followed Apple’s documentation)

@implementation MultiFacetedView
- (NSArray *)accessibleElements
if ( _accessibleElements != nil )
return _accessibleElements;
_accessibleElements = [[NSMutableArray alloc] init];

Create an accessibility element to represent the first contained element and initialize it as a component of MultiFacetedView.

UIAccessibilityElement *element1 = [[[UIAccessibilityElement alloc]     initWithAccessibilityContainer:self] autorelease];

/* Set attributes of the first contained element here. */
[_accessibleElements addObject:element1];

/* Perform similar steps for the second contained element. */
UIAccessibilityElement *element2 = [[[UIAccessibilityElement alloc]     initWithAccessibilityContainer:self] autorelease];

/* Set attributes of the second contained element here. */
[_accessibleElements addObject:element2];

return _accessibleElements;

The container itself is not accessible, so MultiFacetedView should return NO in isAccessiblityElement

- (BOOL)isAccessibilityElement
return NO;

The following methods are implementations of UIAccessibilityContainer protocol methods

- (NSInteger)accessibilityElementCount
return [[self accessibleElements] count];

- (id)accessibilityElementAtIndex:(NSInteger)index
return [[self accessibleElements] objectAtIndex:index];

- (NSInteger)indexOfAccessibilityElement:(id)element
return [[self accessibleElements] indexOfObject:element];


Instead of creating the UIAccessibilityElements, the view elements can also be passed into the array which works absolutely fine.

Some Important Notes

  1. When designing the user interface of the application, it is very important to take into account the people who are colour blind. So, to depict the different state of an element with different colours may not be the wisest of choices
  2. For non trivial controls, it is really important to let the user know what it does or how to operate it. For example, if you have created this super cool knob which can be rotated to select different options, it would be really necessary for the voice over to announce that clearly
  3. If you have a hyperlink in the application, which takes the user outside the application, it is of utmost important to make the user aware of the fact in voiceover
  4. As the user taps a control if some change happens to the screen, be it very minimal, the user would love to know about that. So, if because the user entered a great password in the password input textfield whilst creating an account, the “SignUp” button gets enabled, it is important to let the user know that the button got enabled
  5. Ensure that the elements that are hidden are not announced as this will create confusion for the user


I have noted down everything I have experienced while working with accessibility for iOS. I will continue to add to this article any new learnings as and when I encounter it. If you liked this article, let me know by posting a comment. Hope this helped!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s