You may have recently attended a meeting where you were put on the spot to talk about mobile app accessibility. What is it, specifically? How does our mobile app become accessible? Where do we start?

After promising your boss that you “will look into it”, you may have hit up Google and found content on some notable lawsuits that are holding businesses accountable for accessibility, from Target to Domino’s Pizza. You may have also found pages and pages of information on website accessibility, but not enough on mobile app accessibility. So what now?

How do we define native mobile app accessibility?

Mobile accessibility is about allowing a widely diverse population of people to successfully access and interact with your mobile product. 15% of the world’s population has a disability, and many of those disabilities directly affect how they interact with the physical and digital world every day.

This diverse group includes people with visual impairments, motor limitations, hearing loss, and other conditions, which often require assistive technology or simply a different way of approaching, viewing, and interacting with your mobile experience.

Mobile app accessibility is achieved through a combination of user experience and development, from the correct color contrast to writing code in a way that will allow screen readers to correctly recognize buttons.

Here are the 4 areas to evaluate on your mobile app:

To ensure proper accessibility in a mobile app, the following must be considered. There is no gray area with accessibility — it’s more binary. Either it’s accessible, or it is not.

1. Check Color Contrast

Color Contrast ensures that low-vision or color blind users can clearly read and understand the content. All text and UI elements that are important for performing an action or comprehending content must meet at least a 4.5:1 contrast ratio (Level AA compliance). For all the designers out there, I quite enjoy and recommend using the Sketch Plugin for color contrast to test your app designs.

2. Allow For System Font Sizing

Users with low vision can set their default font size to be larger, making it easier to read text on the screen.

Eleven styles can be set for dynamic type sizes within the iOS Human Interface Guidelines. These styles provide structure around how text sizes up so that users can choose their preferred text size. The text styles aren’t as structured on Android. All text can size up based on an individual’s native phone settings. As long as an app’s interface is designed to be flexible and is given the right structure by both design and development, text sizing changes should not break the user’s experience.

Sometimes, sizing fonts breaks UI elements. These elements should be fixed or made flexible to the sizing needs of the content. The best course of action is to consider accessibility during the design phase to avoid these forehead-slapping scenarios.

3. Help Screen Readers Do Their Job

These modes are for visually impaired users. VoiceOver is a gesture-based screen reader built into iOS, while TalkBack is Android’s native gesture-based screen reader. Android users can access shortcuts by swiping down and then right in a continuous pattern creating an “L” gesture. Either can be enabled on any device through Settings.

Make sure interactive elements are clear

All elements on the screen that can be tapped, like buttons, must be coded to tell the screen reader that the element is more than just text; it’s an interactive element. And the action that the element performs needs to be made clear as well. For example, a save button would be called out as “Save, button,” or a phone number would be read out, then called out as “link.”

There could be a pencil icon to edit content, but it should not be read out as “Pencil,” but rather, “Edit,” which tells the user exactly what action they could do by selecting that icon.

Test loading and swiping

There are a few ways to navigate a screen using VoiceOver: side swiping to move from one element to the next or tapping/dragging a finger across the screen. Side swiping is important to test since some completely blind users seem to rely on this feature more. The swiping creates a mental map of the content in a specific order.

The screen reader may not be aware of information that is loaded slowly on the screen if the screen is improperly coded. With bad configuration, these late-loading elements are not selectable by sideswiping even though they are on the screen and are tappable. Developers can add accessibility events that enable the screen reader to detect newly loaded content.

Tell the reader about graphics and images

Like alternative (alt) text on websites, images in mobile applications also need descriptive text to allow these native screen reader systems to do their job. This text would simply state what the graphic represents or in the case of photos, a brief description of what is happening in the image. This applies to static images, photos, icons, and animations.

Some icons and imagery are supplementary, meaning they may just reinforce a UI element or visually repeat what is already stated in the content. These elements may not need to be labeled or selectable.

4. Test Switch Control (iOS) And Switch Access (Android)

iOS and Android also provide additional native accessibility technology that helps users with motor or dexterity issues.

Switch Control will scan the screen while the user uses an external switch to select elements. Someone may also customize the experience and map action to hardware elements, like the volume switches on your phone. Similar to iOS, Switch Access on Android uses an external switch accessory, external keyboard, or the built-in buttons on the phone.

All selectable elements must be highlighted to allow the user to select anything that would normally be tapped. This is achieved in the application code. Scroll views should also be selectable by the switch to make it easier to scroll.

Test your app and create a plan

Now that you know what you need to evaluate, it’s time to test.

If your app is on both Android and iOS, you’ll need to test both platforms. Consider testing on a variety of screen sizes as well.

If you’re structuring your tests correctly, you’ll want to create test cases to record how to run the test again. You will also collect a whole list of issues, or bugs, that you need to get into development.

Make sure to prioritize by starting with the most critical issues first. “Critical” means that these issues completely block groups of users from accessing your product or from completing actions that are important to your mobile app, like making a payment or buying a spiffy pair of shoes.

Make sure to document everything: the bugs and your progress along with your product’s accessibility plan (complete with timeline).

Now, when you step into that next meeting, you can champion the very worthy cause of making your mobile app accessible to the world. And in the process, you may effectively change your company’s approach to product development from here on out. Nice work!

 

Related reading: 8 Questions to Ask When Developing an Enterprise Mobile App →