I’ve done some limited accessibility testing of native mobile applications in the past, but needed to really dig into it the other day and this post will explain what are the requirements for it.
The Web Content Accessibility Guidelines (WCAG) are essential also for native mobile applications, but there are some success criteria that can’t be tested in the same way as it’s done on the web. That should not be a surprise as web is way more dynamic and adjustable as native mobile applications can be. Just think of CSS and HTML alone – allowing all sorts of different design implementations that are way more limited on native mobile platforms. On the other hand native mobile platforms offer consistency and users are able to recognize their common patterns way easier.
This post is not about WCAG on mobile though, it’s about what you need to have to even start with the testing, so requirements. It’s also written for testers that don’t have access to source control (that is often the case).
Hardware requirements for testing accessibility of native mobile apps
Native mobile applications need dedicated hardware as we know. There are some exceptions but generally we need Apple’s hardware and other hardware that support Android. Then we also need a physical keyboard as a minimum. Some smartphones have it build in but I would suggest buying a dedicated one, so that we can use it on all mobile devices when testing.
But this is not enough. We also need to have different screen-sizes, and therefore we need to have at least a mobile phone and a tablet for both platforms.
Before really thinking about this a bit I didn’t know that we need to have a Mac computer for such tests. Sure, majority of tests will be done on the iPhone and iPad, but to be really effective you also need a Mac computer. Debugging with Xcode is only possible on a Mac.
What kind of phones and tablets should we have? Well it depends on your user base actually. Ideally testers should receive a list of common devices and operating systems to be able to define what kind of devices we should use. Sometimes, in some countries at least, this is very easy. If you have a global market it can be very complicated.
- iOS powered phone and tablet (if possible not only the latest version but also a version before, also depending on the app’s support),
- Mac computer (running Xcode and debugging iOS is actually only possible with a Mac computer),
- Android powered phone and tablet (if possible not only the latest version but also a version before, also depending on the app’s support),
- hardware keyboard that supports both iOS and Android.
Personally I try to use latest versions and a major version before and it’s usually enough. But I am lucky that I know the audience quite well. And the app that I recently tested also made my assumptions a bit easier as the app itself did not support older versions.
For your case – please check your user devices by popularity and try to create a good enough representation.
Software requirements for testing accessibility of native mobile devices
Well, we discussed the operating system versions in the hardware section, but we should also think about other software requirements that are needed to do the job.
Both platforms have it’s own tools for accessibility testing and there are also some other tools that we can use in addition. So software is also kind of essential for efficient testing;
- Google’s Accessibility Scanner (Google Play link that opens in new window),
- Mac OS X Xcode Accessibility Inspector (opens in new window),
- screen-readers for iOS and Android (TalkBack for Android sometimes needs to be installed manually (Android Accessibility Suite on Google Play, opens in new window), VoiceOver on iOS is installed by default),
- Software for making screenshots / videos should possibly also be considered.
I was using Deque Axe for Android before they took it from the Google Play market and I will probably be using some more advanced testing frameworks that seems to be promising (more about them in some other post).
Get familiar with iOS and Android assistive technologies
VoiceOver and TalkBack are the screen-readers. There are probably some others available for Android, but please verify with your end users if that’s really worth it. If it works well for TalkBack it should also work well for others, I would like to think.
Voice control, switches, font settings, contrast settings, animation settings and so on are also worth investigating. I was quite amazed when learning voice control, it really is an useful part of software for people that can’t or won’t touch the phone. What a world of possibilities when designers, developers and content creators join forces and make things accessible.
