Mobile UX and Accessibility: Six Tips for Applying WC3’s Latest Guidance

Accessibility: the practice of ensuring that your content, product, or service can be used by as many people as possible.

Mobile accessibility is a challenging topic, and arguably never more important than before. In the age of social distancing, people everywhere increasingly rely on digital products and services to meet their basic needs. Whether grocery delivery for people unable to venture outside, or productivity tools like Zoom and Slack for employees working from home, the need to make digital products accessible to as many people as possible has never been greater.

An estimated 15% of the global population lives with some form of disability, with that number reaching almost 19% in the US. (source)

In addition to its impact on users, accessibility is also an issue that affects the bottom line of companies in multiple ways. Last October the Supreme Court let stand a lower court decision allowing a customer with visual impairment to sue Domino’s under Title III of the Americans with Disabilities Act (ADA), alleging that the pizza chain’s new pizza tracking app was not compatible with typical screen-reading software. This ruling established firm precedent that companies are on the hook to comply with accessibility standards for their digital services, or face potential legal action. This adds to the long-standing precedent that employers must make reasonable accommodations for their employees with disabilities.

Putting these factors together, it’s no wonder there’s increasing interest in making digital products more accessible. This opens up a pressing question for designers and engineers: how exactly do you do that?

WCAG and Accessibility

Our main guideline for implementing accessibility in our products is the W3C’s Web Content Accessibility Guidelines (WCAG). As the name implies, these standards are designed for web content displayed in a browser. However, the W3 has made some steps to address how WCAG should be interpreted in the context of native apps, and the most recent WCAG update (2.1) addresses some issues specific to web content displayed on a mobile device (such as device orientation).

WC3 has provided the guidance that “Overall, WCAG 2.0 is highly relevant to both web and non-web mobile content and applications.” However, it can still be challenging to interpret the success criteria when designing a native app. But it’s not impossible. Fuzz’s engineers and designers have collaborated to apply WCAG 2.1, alongside updated guidance from W3. The six principles below are ones we’ve developed to guide our teams in creating truly accessible mobile products.

1. Work with the tools Apple and Google provide

90% of the battle when building an accessible app is ensuring that content is designed and developed to play nicely with the built-in accessibility tools provided in iOS and Android. The most well known of these tools are the screen readers Voiceover (iOS) and Talkback (Android), and a bulk of WCAG success criteria can be fulfilled by ensuring that all content works robustly well with either tool. Beyond that, both operating systems have a variety of other accessibility tools that every designer and developer should explore.

Many of these built-in tools provide means for satisfying success criteria that specifically apply to markup-based content. A good example is WCAG criteria 1.1.4: Resize Text, which is supported by iOS via both the Zoom tool and Display & Text Size settings, and by Android via Font Size and Magnification- without these built-in tools, developers would need to implement their own ad hoc text sizing functionality.

Unfortunately, some WCAG criteria just don’t have a good solution at the moment. An example is 1.4.12: Text Spacing, which calls for allowing users to override text styling and increase the spacing between letters, words, and/or lines to aid legibility, but only in markup based layouts. Currently, there are no OS-based settings to adjust these spacings, and native apps are technically excluded from this success criteria, which raises an interesting dilemma: should we strive to implement these features with custom functionality, even if it’s not required? There’s not yet consensus in the engineering community on this question.

2. Integrate accessibility into the content strategy and creation process

Writing good app copy means writing copy for everyone, including those using accessibility features (and especially screen readers). Both Voiceover and Talkback provide the ability to present additional context about user interfaces and elements inside them via Hints and Labels.

Today, writing accessibility text is broadly overlooked in design and engineering processes; each discipline assumes the other will take care of it, so this copy slips through the cracks as a result. The workflow is then to retroactively add hints and labels to all the elements in a layout to make it more accessible, which is a difficult process that can lead to muddled and confusing results.

Integrating the process of writing accessibility text into the larger phase of content strategy and development can help identify early on where users relying on accessibility might get hung up or confused, and save time and effort later on.

3. Ensure there are fallbacks for the gestures most people take for granted

Certain navigation and interface paradigms present huge challenges to users with disabilities. For instance, complex multi-touch gestures may be difficult or impossible for some users. Additionally, users with Voiceover or Talkback active lose the ability to control swipe-based interfaces, so instances where users might intuitively swipe to navigate must have clear indicators and some sort of tappable element for those with alternative inputs to use as backup. This also applies to drawers, menus, or other elements that are introduced and dismissed purely by gestures.

Similarly, some common user interface paradigms simply don’t play well with screen readers and/or alternative inputs. A great example are rich embedded maps, such as a location finding interface. Embedded maps from different providers have varying levels of support for accessibility features, but in almost all cases they’re extremely difficult to navigate. In these cases, WCAG criteria 2.4.5: Multiple Ways calls for a backup method of browsing or selecting content, such as a simple tap from a list. Users with a screen reader will also need clear cues to find and use said backup.

4. Provide clear, consistent navigation and hierarchy

There are a number of good reasons to make navigating your app as simple as possible, accessibility aside. However, for those who need to make use of accessibility features, clear and cogent design is a huge premium. When a screen reader is active, or the screen is highly magnified, clear navigation and hierarchy can make the difference between finding important information and getting lost in unimportant details. Achieving this is a combination of efforts — solid screen reader compatibility, good design, and concise, clear content/calls to action.

5. Don’t forget to support alternative input devices!

It might be a surprise that both iOS and Android support external physical input devices such as keyboards (and even wireless mice as of iOS 13!). Some users rely on the precision and control provided by a keyboard, but luckily many of the challenges in adapting content to alternative input devices overlap with providing Voiceover/Talkback support.

6. If possible, embrace landscape (or at least make it useable)

For some users, using their device in landscape mode is practical or essential (ie, a phone mounted on a wheelchair arm). Unfortunately, many popular apps don’t currently support landscape mode, so it will likely take time for this one to catch on. Nonetheless, as designers and engineers, we can advance the importance of this in early conversations around the requirements of what’s critical to build.