So accessibility is really about making sure all users, regardless of abilities, have full access to all of our products and the great features you put in your apps, and that means we get to focus on users and think about how users with these different abilities use our features.

-Ian Fisch, WWDC 2015

How can you quickly determine the extent to which your SAAS is accessible? What percent of your customers are affected by the level of accessibility in your app?

Envolve’s companies offer tools built with employer benefit programs in mind to help employees track and maintain healthy lifestyles and good habits.  Their digital tools offerings include web portals as well as mobile apps on both iOS and Android platforms.  The mobile apps are hybrid applications, meaning that they are native applications that utilize a web container to load web content.  By following a hybrid approach, Envolve was able to leverage existing content on their web portal in the mobile apps during the interim period while more robust native solutions could be developed.  Recently Anaara was tasked with updating Envolve’s mobile applications to make them accessible, particularly with regard to voice over functionality.  Following is a high level overview of how we achieved this, in particular with regard to the iOS mobile application.  For more technical details see the Resources & References section at the end.

Apple’s platforms are “accessible to the core” – Apple has already done most of the work for us in implementing accessibility.  So the main steps to ensure accessibility in our mobile app were:

1. Accessibility Audit – determine the extent of accessibility already supported by the application out of the box, identifying any problem areas (specific custom controls, behaviors etc.)
2. Ensure all UI elements have accessibility labels that make sense to users in the context of the application, and provide additional accessibility detail where appropriate.
3. Adding custom dynamic notifications for special layout contexts.
4. Determine the percentage of mobile users who actually utilize accessibility, i.e. determine the ROI of accessibility and the importance of it moving forward.

Performing the accessibility Audit

This part is actually a lot simpler and faster than you might think.  First, turn on the accessibility shortcut in iOS, which allows you to triple-press the home button on iPhone to turn voice over on and off.  To do this, go to Settings->General->Accessibility, and set the last item, Accessibility Shortcut to VoiceOver.

Second, open the app and use the two-finger swipe down gesture to make VoiceOver read all the items on the screen.  If anything gets skipped, you’ll know you have an issue.

In our case, we had a few specific challenges to deal with.

First, because the app is a hybrid app, with a web-container loading dynamic web content, accessibility doesn’t always work seamlessly between he native content and the web content.  A separate effort was needed to ensure that the web content was accessible, at the level of the html / javascript being sent from the server.

Secondly, this app utilizes a side menu.  The mechanics of the side menu were such that, when a menu button (typical “hamburger” button in the upper left corner of the app) was tapped, the main screen slid off to the right, but was still partially visible.  From the perspective of VoiceOver, not only was the content on the main screen still visible, but it took priority over the content in the side menu.  The result was that the two-finger swipe down gesture resulted first in the main screen being read, and then the side menu content being read.  In reality, we wanted VoiceOver to treat the main screen as invisible when the side menu was open, with the exception of the menu button itself, which was on the main screen but needed to be accessible at all times.  The solution was to change a property on the web container (in the main screen) to make it invisible to Accessibility whenever the side menu was opened (UIAccessibility.accessibilityElementsHidden).  Additionally, we wanted the user to be aware of the state of the UI when the menu was opened or closed.  For this, we had to dig a bit deeper than the standard accessibility properties, by adding a custom notification whenever the menu was opened or closed, like this:

UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, "side menu open")

Another issue brought up by our Accessibility Audit was that the side menu items were being read by VoiceOver as labels.  We wanted them to be treated as buttons.  This was also a very simple fix – using Accessibility Traits we set the menu items to UIAcessibillityTraitButton.

Finally, we wanted to give the user additional information on certain UI elements.  In iOS accessibility, if you make use of “hints” the effect of this is that after the VoiceOver reads the Accessibility Label on a UI element, it pauses.  If the user doesn’t take some action right away, the VoiceOver then elaborates further using the text in the Accessibility Hint.

Now that we had invested some time and effort into making our app accessible, we wanted to know what the impact of our work was.  What percentage of the mobile users actually make use of the accessibility features on their devices?  For this Google Analytics is extremely valuable.  When the app launches, we can detect whether VoiceOver is turned on or not.  If it’s turned on, we simply fire a Google Analytics event which is then aggregated with other such events in a Google Analytics dashboard.

Resources & References:

• NSHipster’s Article on UIAccessibility
• Apple Developer Site on Accessibility
• Test Accessibility on Your Device with VoiceOver
• Making Your iOS App Accessible
• UIAccessibility Protocol Reference
• Dynamic Notifications for Accessibility
• 2015 WWDC talk on iOS Accessibility
• 2016 WWDC talk on What’s new in Accessibility (iOS 10)

SaveSave

SaveSaveSaveSave

SaveSaveSaveSave