When people ask questions about doing accessibility testing on mobile devices they are often making two basic assumptions. The first is that accessibility testing on a mobile device is completely different from accessibility testing on a laptop or a desktop. The second is that the only user population affected by mobile accessibility are blind or visually impaired people. While it is true that the primary focus may often be on screen reader users, there are many other mobile users that require accessibility considerations as well.
People with low or limited vision, cognitive issues, mobility, and dexterity issues are all affected by a lack of accessible design on a mobile device.
- Low contrast color schemes, small text, and images that cannot be resized: all of these things can pose major issues to people with low vision.
- Because of the increased emphasis on brevity and icon usage on mobile devices, people with dyslexia and other cognitive issues may have problems with understanding the content or finding interactive controls.
- Keyboard accessibility and focus management can present problems for sighted users with motor and dexterity issues, and individuals who may have external keyboards and other manual switches that they use in conjunction with their mobile devices.
- Very small active touch regions can be a problem for all users, but especially for those with motor or dexterity issues.
The bottom line: Even though the approach to testing may be a little different, the people who use apps and websites on mobile devices will have very similar accessibility needs as they do with desktop apps and websites. Customers still want to review and compare products and make purchases. Subscribers still want to update their profile information. Just as mobile platforms provide us with new methods to meet user needs and engage with them in a unique way, the accessibility testing techniques for ensuring that those new methods don’t leave anyone out of the experience.
Getting started with manual testing
Manual testing a mobile website or app can be broken down into two basic tasks: visual inspection and screen reader/keyboard inspection.
The visual inspection is exactly what it sounds like; examining the mobile website or app to see how color and images are used, and where associated controls and text are located in relation to each other.
If you know the designer who worked on the app you are testing, you can probably get a list of the hex values for the colors that were used. Otherwise, it can be helpful to take screenshots of the different screens and screen states, open the screenshots on a desktop or laptop, and use an eyedropper tool to sample the colors. Color contrast testing is the same on a mobile device as it is on a desktop; normal text should have a minimum contrast of 4.5:1 and large text should have a minimum contrast ratio of 3:1. With the advent of WCAG 2.1 color contrast requirements have been extended to active interface controls and graphical objects, which should have a contrast ratio of at least 3:1.
Text resizing is as important on mobile as it is on the desktop, and some mobile browsers and apps will override common resizing methods. On the mobile browser, check to make sure that the pinch-zoom method of resizing is not disabled. In apps, make sure that OS level font size settings are reflected.
Don’t forget to look at both the portrait and landscape orientations on your mobile device. While the two orientations don’t have to look the same, the app shouldn’t be locked to a single display orientation unless a specific display orientation is essential. All content and functionality should be visible and usable in both orientations.
Screen Reader and Keyboard Inspection
Pro tip: If you are testing a responsive website, always test the desktop version first. You can use the Chrome Developer Tools to emulate different mobile devices and use the
keyboard/screen reader to test areas that are likely to be problems; mobile navigation panels, forms, modals and pop-ups, and accordions, to name a few. If you do this, always remember to verify the issues you find on a mobile device.
Having the device screen reader active will change the way that you interact with the device, and in many ways is very similar to using a keyboard in conjunction with a screen reader on a desktop, only instead of using the tab key to navigate, you “swipe” the screen. And instead of using the spacebar or enter key to activate an element, you tap the screen. While the basic gestures to navigate an app or mobile website are the same for both TalkBack and VoiceOver, some of the more complicated gestures are different. We have outlined some of these gestures in an earlier article.
With the screen reader on, swipe through the screen from top to bottom. Everything you can see must be presented in a meaningful way via the screen reader. If you have done a lot of accessibility testing on the desktop, you are already aware of what you need to look for when it comes to accessible names, forms and form validation, focus movement, custom controls, and semantic structure. You still need to check for all of that on mobile! While you are testing, we recommend using the global and local context menus, in TalkBack, and the Rotor, on VoiceOver, in order to check things like the link lists, headings and landmarks, and to listen to the screen being read straight through without swiping.
There are also some things that are unique to mobile, that you will want to pay special attention to:
Tables may be different on iOS versus Android. On iOS devices, you should be able to navigate both horizontally and vertically through tables. On Android, you will be limited to horizontal navigation.
Check to make sure that different input types on mobile forms present the correct keyboards when they have focus, for example: the number pad when the user needs to enter a phone number.
- Location and proximity issues are more closely related to the reading and focus order on mobile than on desktop. In particular, make sure that controls are located in the order that a user would expect to interact with them. Mobile navigation bars may mean that screen reader users encounter controls out of order.
- Make sure that nothing activates on the initial touch, and that all functions are activated on the up-event.
- Ensure that mobile users can access alternative input methods.
- If your product uses multipoint or path-based gestures, make sure that all of these can be operated with a single pointer and without complex gestures, unless a multipoint or path-based gesture is essential.
- If the app uses intentional movements to cause action (for example, shaking the phone to turn the page of an ebook) then make sure that the motion can be disabled, and that alternative methods to perform the action are available.
Don’t forget to test your mobile apps with a keyboard, both with and without the screen reader active. Mobile app content needs to be functionable and navigable with a keyboard, and focus should be visible even with the screen reader off. If you want to be an accessibility testing rockstar, you can also set up your Bluetooth keyboard as a switch, and test switch access.
A look at automated testing on mobile
Tools are available for automated testing, and they can be very useful as a supplement to manual testing, but like similar tools that are used to scan websites on desktops, they often cannot provide the rich interaction and usability information that you can get from manual testing. There are also a lot fewer automated testing tools available for mobile, as compared to desktop. One of these is Google’s Accessibility Scanner, which is available for Android devices.
This app will scan the current screen, identify potential accessibility issues, and provide some remediation suggestions. However, it is important to note that the Accessibility Scanner is somewhat limited in what it can examine and report. It can only provide feedback on:
- Touch target sizes (a new AAA guideline in WCAG 2.1)
- Color contrast
- Content labels
- Interactive items
When the app is running, a blue check icon is displayed on the screen, which can be tapped at any time in order to run a scan on the current screen. Items that have been identified by the app as potential accessibility issues will be outlined in orange, and the number of issues found will be listed at the top of the screen in a control panel that will allow you to select how you view the issues, as well as how you can save or share the report.
The detail view of the individual issues will describe what the accessibility issue is, offer a (sometimes very) brief suggestion for how it can be fixed, and a link to more information on the issue. That “Learn more” link is extremely useful, as it not only offers more information about the accessibility issue, interface design tips, and manual testing tips, but in many cases also goes into great depth as to what a developer can do in order to fix the problem and avoid committing the same kind of error next time.
As you can see in the first screenshot of the Accessibility Scanner, not all issues, even those it is able to test for, may be caught. Indeed, it looks like there are more color contrast issues on the screen than the app found and flagged. This is a good reason why automated testing using apps like this is may be an excellent supplement to manual testing but should not necessarily be considered a replacement for it and should not be relied on as the sole source of accessibility information.
Putting it all together
Using an automated test to scan screens of a mobile app or website can give you some valuable insight into the quality of its code as well as what problem areas you might want to pay extra attention to during a manual assessment. However, because of the limitations of automated testing, it should not be considered a replacement for manual testing. Manual testing expands
on the issues uncovered during an automated scan and gives additional insight into the accessibility and usability of more complicated interactions and workflows.
Accessible and usable apps and websites on mobile devices benefit everyone, not just people with disabilities. That’s why testing apps and mobile webpages for accessibility is so necessary. If people are accessing your product on mobile devices, you owe it to them to have a plan in place to ensure that you deliver the same level of accessibility there as you would on a desktop.
What kind of approach do you take when it comes to mobile accessibility assessment? Tell us what works well for you, and what you find to be a challenge!
This is the fourth and final article of a series taking you through mobile accessibility basics for Android and iPhone. We have already introduced TalkBack and VoiceOver, discussed the ins-and-outs of color, contrast, and magnification, and touched on switch access.