3 accessibility testing tools for Android

The Web Accessibility Content Guidelines (WCAG) 2.1 recommendations explain the success criteria for making web and mobile apps accessible to people with disabilities. The guidelines are pretty straightforward, but can be difficult to eyeball, as they make very specific requirements about the visual qualities of text and other on-screen elements. As someone without any recognized disabilities, I find it difficult to spot potential problems on my own, so it’s helpful to use tools to point out where they occur.

If you don’t know if your app is WCAG compliant, it probably isn’t. Here are three tools that help you get there. Note that these tools do not certify an app for WCAG compliance — they merely help spot certain issues that are possible to assess using Android APIs.

• Google — Accessibility Scanner (Play Store)
• Deque Systems — Accessibility Engine (axe) for Android (Play Store, web)
• Microsoft — Accessibility Insights for Android Service (web, GitHub)

These tools require only an installed APK to test on. There are other tools that take a more programmatic approach to testing during development (such as Espresso’s accessibility checking), but I won’t cover those here.

The tools provided by Google and Deque are very similar in that they are both provided as Android apps available as Google Play store downloads. They are easy for anyone to use, even without Android development experience.

The Microsoft tool is primarily operated as a desktop app (not an Android app like the other two), and requires Android development tools to use. If you are not comfortable with Android app development tools, I would skip it entirely, as it won’t be easy to set up and use.

One important note about all of these tools: they make use of the Android Accessibility Service APIs, which require rather intrusive permissions. In order to operate, they will ask you for permissions to read your screen and keyboard input like this:

Granting this type of permission to a malicious or broken app can lead to security issues, so I strongly recommend using these types of accessibility tools only on emulators or devices dedicated for development. If you don’t trust any of these tools and their developers explicitly, simply do not use them at all.

Google’s Accessibility Scanner vs. Deque’s Accessibility Engine

Since Google’s and Deque’s tools are both operated the same way, I’ll compare them with each other. When active, they will each provide a floating, movable button on screen, visible all the time. Pressing this button will activate the tool on the current screen, providing some diagnostics.

Deque’s app provides a few of its own sample screens that are intentionally populated with some WCAG accessibility violations that will trigger its rules for demonstration purposes. After enabling the scanner, it shows a menu

Color contrast

Deque will dutifully spot the accessibility violation that it staged on its own screen:

It’s kind of difficult to see, based on the way it’s highlighting the element, but it’s saying that the text “Color Contrast example” doesn’t have enough contrast, according to the WCAG. Now I’ll run Google’s tool on the same screen:

It’s interesting to note that Google found 5 violations on 4 UI elements.

Deque considers the second instance of “Color Contrast example” to be “incomplete”. But, by default, Google flags them both equally if they’re measured with a contrast ratio anywhere below 4.5:1. This threshold can be configured in the app’s settings.

Google flags the red text “Critical” also as a contrast violation. If you click the element, you’ll get a more detailed analysis:

To me, this is much more helpful information than Deque provides. It gives the computed contrast ratio, as well as the specific colors it found in the view that it used to make the computation. It also provides a “Learn more” link with every violation so you can read very detailed information about why this is a problem, and what you can do to fix it. It even provides a link to a contrast ratio calculator so you can experiment easily:

Also on that screen, Google flagged the text “Reason it’s an issue” because it’s identical to another label below it on the same screen:

A possible solution here would be to number or otherwise label the items on the screen so a screen reader could more effectively announce them uniquely.

Active views

On Deque’s Active Views test screen, it spots the staged violation of a button that doesn’t have a text label:

Google finds this as well:

Again, clicking through to “Learn more” will give you some steps to take to understand and fix the issue.

Other features

Both Google’s Accessibility Scanner and Deque’s Accessibility Engine have the ability to share results to other apps using Android’s sharing mechanism. But what really stands out about Google’s tool is the ability to record a session and spot accessibility problems the entire time. It also logs a history of violations so you can return to them at any time after recording.

All this considered, Google has the more polished and useful tool. However, Deque provides its ruleset engine as an open source library. My sense is that the app is mostly provided as a showcase for this rules engine. In fact, Microsoft’s Accessibility Insights for Android Service uses exactly this library.

Microsoft’s Accessibility Insights

Microsoft’s tool is not much like Google’s and Deque’s. It’s implemented as a desktop application, and requires installation of a headless service that you install on the Android device. The app connects to the device over an adb connection, and uses that to pull down accessibility data.

The big downside to this scheme is that you must have Android development tools installed, and be able to work them from the command line. You also need to be able to configure both the computer and device for Android development. If you don’t already know how to do these things, you’re probably in for a bit of a slog to get it all to work. But once you’re comfortable with all that, the desktop app is relatively easy to use. It will scan a screen and show you details about violations, as well as some help to fix them.

Since it’s using the same rules engine as Deque, it will find the exact same violations. What Microsoft’s tool adds, however, is some conveniences around reporting the violations using tools you might already know. Using the overflow menu at the bottom right of an issue, you can quickly file an issue on GitHub or Azure Boards. It essentially pre-populates the issue form with details. You can also export the data as HTML. What’s really disappointing here is that it doesn’t give you direct access to the screenshot it took, so the report itself is not very easy to work from. You would have to take a screenshot of the app window (as I did above) and get the screenshot out of there, and manually attach it to the issue.

Which would you prefer?

I suggest trying all three to find out which one works best for you. If you’re not an Android developer, I would skip the Microsoft tool entirely, as it has a lengthy and complicated setup, and it finds the same issues as Deque’s tool. Google’s app is easy to use, works smoothly, and offers very helpful advice for understanding and fixing accessibility issues.