Importance of accessibility testing for mobile
Statistics show that more than 60% of internet traffic comes from mobile phones. Considering that most of that time is spent using mobile applications, it’s clear that making those applications accessible to everyone should be a part of every application’s strategy.
This chapter will cover testing the mobile applications, while web usage on mobile will be covered separately.
When testing mobile applications, it’s important to keep in mind that users use mobile phones in various ways. For example, some people use screen readers, some use other assistive devices like braille keyboard, head movement tracking tools, or sip-and-puff devices, and some use them with different display settings such as increased text size or bold text. When our app is not designed with accessibility, using any of these could strongly impact the user experience or make applications completely unusable.
But, it’s not only that differently-abled people who use assistive technologies and tools are affected. For instance, if somebody uses our app on a bright sunny day, a proper contrast would be as useful to them as it is to users with low vision. Not to mention that closed captions on videos can be as useful to someone who forgot their headphones in loud surroundings as it is to someone with hearing impairments. Accessible apps make better UX for everyone.
With all this in mind, it’s clear that accessibility testing is an important part of usability testing.
As with all testing, it’s important to start with testing efforts in the earliest possible phase – if we start testing our apps for accessibility while they’re still in the wireframes phase, we can avoid expensive fixes later in the development cycle.
To start with auditing your mobile apps for accessibility, it’s good news that you don’t need fancy tools or coding experience. Although some bits of accessibility testing can be automated, manual testing, enhanced with some free and easy-to-use tools, will give you a real sense of the experience you are offering. Self-auditing your app, reporting bugs, and then retesting them to check that fixes work as expected will greatly enhance the accessibility of your app.
Also, testing your app this way – using it in a way you never did before, is a great learning experience for any software tester. Looking at your app’s UX from a different perspective can give you great insight and help you with ideas for improvement.
Mobile accessibility and WCAG
As already explained, WCAG is an abbreviation for Web Content Accessibility Guidelines. As the name says, they are mostly focused on the Web. Although WCAG should be device agnostic, in WCAG 2.1, which is a recommendation from W3C since 2018, guidelines are still difficult to apply for native mobile applications.
That’s not strange when we consider that WCAG 2.0 was finalized in 2008. That’s just one year after Apple released the original iPhone. Technology has made great leaps since then, and the number of mobile users has increased in a way that was hard to imagine back then.
WCAG 3.0 is a new version estimated to be finished by the end of 2023. The plan is to account for those technological changes, especially with mobile and wearable devices and other Internet of Things (IoT) technologies. AGWG has also decided that WCAG no longer stands for “Web Content Accessibility Guidelines”; from WCAG 3.0, it will be the abbreviation of “W3C Accessibility Guidelines”.
But we will need to wait for them until the end of 2023 – probably even longer. Until then, we need to make the most out of WCAG 2.1, so in the next chapters, we will focus heavily on its guidelines. To understand how WCAG 2.1 applies to native mobile applications development, Infinum Mobile Standards are a great place to start.
WCAG’s four principles of mobile accessibility
To make all digital content accessible to everyone, WCAG has four guiding principles: it requires content to be Perceivable, Operable, Understandable, and Robust.
When testing the accessibility of mobile applications, it is important to test against all four of these principles while keeping all areas of disabilities in mind.
Apple defines them as Cognitive, Motor, Vision, and Hearing, while Android uses Audio, Vision, and Mobility when talking about the areas. In the next chapters, we will make sure to cover them all when explaining how to test.
Very broadly (it will be explained in more detail in the next chapters), according to WCAG’s definitions it would mean that the software that we create needs to be:
Perceivable: Information and user interface components must be presentable to users in ways they can perceive.
For software testers, we need to test so that users can perceive all important information on the screen, no matter the disability they might have. This would include labels for screen readers, videos and audio content captions, ensuring that no important information is communicated with color only and similar.
Operable: User interface components and navigation must be operable.
From a QA perspective, we need to ensure that all users must be able to operate the interface – it cannot require action that a user cannot perform. For example, we need to test that users can operate the app with their voice or a physical button (think of Switch access/Switch control features, they will also be explained in the next chapters). Also, they have time to perform important actions, and there are no flashes or animations that could cause unpleasant effects or even seizures to users who are sensitive to them.
An important part of ensuring that the app is operable includes checking that the app is navigable as well. The navigable app provides ways to help users navigate, find content, and determine where they are.
To find out if our app is navigable, we need to test if the navigation through our app feels natural – with and without accessibility features turned on.
The software tester’s responsibility is: to make sure that all screens in the app have proper titles; all hyperlinks are properly named and easily identified; it is easy for all users to skip some repetitive content and go to the next section (think Instagram’s stories); the content on the screen is grouped into logical sections and similar.
Understandable: Information and the operation of the user interface must be understandable.
This means that users must be able to understand the information and the operation of the user interface (the content or operation cannot be beyond their understanding).
This principle is firmly dependent on the first two – if we made sure that our app is both perceivable and operable, chances are that it will also be easy to understand. Still, there are some checks that the QA team should make: check that the screen reader can recognize the app’s language and that the app’s experience is predictable (no sudden changes in the context or similar). If any error occurs, it is appropriately communicated to the user, with suggestions if needed and similar.
Robust: Content must be robust enough to be interpreted reliably by various user agents, including assistive technologies.
For mobile testing, this means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible) – for example, mobile applications should be accessible on various mobile devices. It should be backward compatible with older versions of screen readers and similar.
Levels of accessibility
As already mentioned, WCAG has three levels of accessibility A (lowest), AA (midrange), and AAA (highest). Conformance on high levels includes conformance on lower levels – for example, by conforming to the AA level, the app also meets the A level.
A short explanation of each of these levels is as follows:
- A – Essential: basically prohibits elements that would make the website inaccessible
- AA – Ideal Support: the website is usable and understandable for the majority of people with or without disabilities
- AAA – Specialized support: – your site is accessible to the maximum number of users, and the UX is easy for most of them
Most accessibility regulations around the world use AA as their guideline in conformance. While level AAA would be ideal, even W3 explains that it should not be a standard for the whole industry – the applications using it as their standard should be the ones that cater to differently-abled people and the elderly as their users.
Based on all of this, this chapter will focus on the AA level.