Introduction
Last modified on Fri 17 Mar 2023

Introduction

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:

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:

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.