In these articles, our Android team will address the most common accessibility issues on the Android platform, give you guidance on how to solve them and show you best practices and tools that you can use when polishing your app to be accessible.
At STRV, we pride ourselves on always chasing the ultimate meta of building top-quality digital software. With that said, we understand that multiple factors contribute to the overall quality of software. One of those being accessibility.
Accessible software benefits businesses. A study of Fortune 100 companies indicates that disability inclusion, as part of an overall diversity strategy, is common practice among high-performing businesses driving innovation, enhancing the company's brand, increasing market reach, minimizing legal risk, etc.
An Android app is a user-facing product which is assessed from the accessibility point of view. The journey of an accessible product starts with accessible specification and design. Developers are not able to produce an accessible application without this necessary condition.
On the other hand, once the accessible designs are ready, the burden of creating an accessible product falls on the developers' shoulders. That’s why we created an Accessibility Guide for Android Developers. These articles are a reflection of that guide.
To begin with, we’d like to cover the basics, as well as tools that help you uncover accessibility issues.
Please note: We will be using the term a11y as a substitute for “accessibility.” The “11” stems from conventions in software engineering and Information and Communication Technology that shortens words by substituting middle letters with the number of those letters. There are 11 letters between the "a" and the "y," so accessibility becomes a11y.
The Web Content Accessibility Guidelines (WCAG) cover a wide range of recommendations for making content more accessible. From the name, it may seem that it is related to Web only, but almost every rule is applicable to Android apps as well.
The general description of WCAG can be found on W3.org.
You can see the simplified summary of what was added in WCAG 2.1 (e.g., orientation change requirements, labeling, etc.).
WCAG 2.0 Conformance Levels
WCAG 2.0 guidelines are categorized into three levels of conformance in order to meet the needs of different groups and different situations:
- A (lowest)
- AA (mid-range)
- AAA (highest)
As an example for those levels, we can take color contrast, where AA requires a contrast ratio of 4.5:1, while AAA requires 7:1.
Working with a11y doesn’t come down to all or nothing. It’s not pass or fail. A11Y issues in an app can be divided into categories, with each category representing different severity. And some issues can be marked as partially working — which is always better than failure.
Here are the most useful tools for Android developers.
Accessibility Scanner is probably your best friend while working on a11y improvements.
It allows you to reveal all critical issues, even without knowing anything about a11y and with zero interest in the a11y topic. The scanner can help you analyze three main categories:
- Color Contrast
- Content Description
- Touch Target Size
TalkBack is the most used tool while working with a11y, as it is the primary screen reader for Android. TalkBack should be your favorite tool, but using it can sometimes be difficult (especially when it comes to gestures) and requires some practice.
Unlike the Android Accessibility Scanner, this tool does not show or tell you any issues on its own. You have to try everything yourself, click on all views, do all possible actions and listen to TalkBack.
See the TalkBack tutorial about how to use it and how powerful the tool can be.
Next Up: Android Common Topics
In the coming weeks, we’ll be publishing Accessibility at STRV: Android Common Topics, Pt. 1 and Pt. 2, where our Android team goes into a variety of common issues and how to identify and solve them. We will then end the series with the fourth article, Best Practices.