Axe Android

Automated WCAG 2.0 and WCAG 2.1 Accessibility library for Android Applications. Not an Android Developer? Check out the rest of the axe family.

Results in Minutes

The easiest way to get started with axe-android is to download the Official Axe for Android Google Play Store Application. Get results on your phone in minutes.

Table of Contents

• Rule Overview
  • Axe Manifesto
  • Two Week Pledge
• Utilizing the Analysis Library
  • Implement Abstract Interfaces
  • Track Event Stream
  • Run Axe Android
• Configuration Strategies
  • Chipping Away
  • Chopping it Off
  • Targeting Standards
  • Avoiding False Positives

Rule Overview

	Rule ID	Issue Type	Unique to axe
1	Active View Name	WCAG 2.0, WCAG 2.1	❌
2	Color Contrast	WCAG 2.0, WCAG 2.1	❌
3	ImageView Name	WCAG 2.0, WCAG 2.1	❌
4	Touch Size - WCAG	WCAG 2.1	❌
5	Touch Size - Custom	Best Practice	❌
6	CheckBox Name	Best Practice	✅
7	Don't Move Accessibility Focus	Best Practice	✅
8	EditText Name	Best Practice	✅
9	EditText Value	WCAG 2.0, WCAG 2.1	✅
10	Switch Name	Best Practice	✅

Axe Manifesto

Accessibility is hard. Sorting through endless reports, long explanations, and false positives make it worse. Our Rules will be:

• False positive free.
• Broad enough to be generally applicable.
• Discrete enough to be easy to identify and fix.
• Encourage Vendor, OS Version, and Assistive Technology agnostic solutions.
• Released to Beta any time we have something we are confident in release.
• Released to Production
  • As we have substantive new features that are stable... like a New WCAG Rule.
  • Any time false positives are fixed and manual tests validated.

Two Week Pledge

When a false positive is reported to GitHub Issues AND

• We have enough information to confirm it is a false positive.
• It is not specific to a given flavor.
• It is not specific to an Android Version more than 2 major versions back.

we will do one of the following

1. Fix the false positive.
2. Demote it to Experimental.
3. Respond in some other substantive way given the nature of the report.

within 2 weeks AND the view hierarchy that exposed that false positive will remain a part of our test suite until that test case is no longer valid.

Utilizing the Analysis Library

Axe Android is simple to use, though requires a bit of knowledge of Android Accessibility to get started. Axe Android is a pure Java library. This helps encapsulate us from the volatile Android Accessibility Ecosystem and guarantees that anyone can run our library on ANY version of the operating system. There are no dependencies on any version of the Operating System nor any particular version of the Support Library. Because of this, you'll need to write a little code to get started. The process can be broken down succinctly like this:

1. Implement abstract interfaces.
2. Track the Event Stream.
3. Build AxeContext, AxeConf, and AxeImage data.
4. Run axe and consume results.

Implement Abstract Interfaces

Axe Android is a pure Java library. This allows us to keep our rules very concise and human readable and encapsulates us completely from the Android Ecosystem. However, it requires more input from those who want to utilize the library. Namely that the provide implementations of the following abstract interfaces.

AxeView.Builder

An AxeView.Builder builds an AxeView. You should be able to create a wrapper for this information quite easily by implementing this interface within a Class that contains either an AccessibilityNodeInfo instance or a View instance.

Each function in the AxeView.Builder interface has an associated, identically named, final property in AxeView. The Java Doc for these properties in AxeView.java is the best place to go for documentation on what these functions are expected to return.

AxeEvent.Builder

The AxeEvent.Builder builds an AxeEvent. Is this sounding familiar yet? You should be able to create a wrapper for AxeEvent by implementing this interface within a class that contains an AccessibilityEvent.

Again, the documentation for what the properties are is best found agains the JavaDoc for the final instance properties of their associated object... AxeEvent.java.

AxeImage

We need access to image data to run Color Contrast analysis. An object that wraps a Bitmap instance would be the easiest way to supply this information. Look at AxeImage.java.

Track Event Stream

This sounds scary but it's really quite simple. Utilizing the AxeEvent.Builder interface you built above in conjunction with our AxeEventStream object, track AccessibilityEvents as they flow either

• out of yor application
• into an AccessibilityService

For example:

AxeEventStream axeEventStream = new AxeEventStream();

@Override
public void onAccessibilityEvent(AccessibilityEvent event) {
  axeEventStream.addEvent(new AxeEvent(new YourEventBuilder(event)));
}

You then feed this information into the AxeContext when you go to run axe.

Run Axe Android

With these interfaces implemented running axe is very simple.

Axe axe = new Axe(new AxeConf());

// Create an AxeView object from your AxeView.Builder implementation
AxeView axeView = new YourAxeViewBuilder(rootViewToBeAnalyzed);

// Create an AxeDevice object to help identify the device under test.
AxeDevice axeDevice = new AxeDevice(dpi, deviceName, osVersion, heightPixels, widthPixels);

// A screenshot to facilitate ColorContrast analysis and help identify issues.
AxeImage axeImage = new YourAxeImageClass(screenshotData);

// Run Axe and Get Results.
AxeResult axeResult = axe.run(new AxeContext(axeView, axeDevice, axeImage, axeEventStream));

Configuration Strategies

There are a lot of different reasons to want to configure Axe. Below are a few configuration strategies and motivations for these strategies. We'd LOVE to hear about other ideas you have.

Chipping Away

Accessibility can seem like a huge task. One way to make the load seem a little lighter can be to focus on fixing one set of issues at a time. The easiest way to do that would be to set up an AxeConf object like this:

AxeConf axeConf = new AxeConf()
    .removeStandard(AxeStandard.BEST_PRACTICE)
    .removeStandard(AxeStandard.PLATFORM)
    .removeStandard(AxeStandard.WCAG_21)
    .removeStandard(AxeStandard.WCAG_20)
    .addRule(ColorContrast.class);

Chopping it Off

The motivation for this is similar to Chipping Away but instead of focusing on one Rule at a time, you focus on one View at a time. For example, your Login Workflow would be a great place to start. A great configuration for this would be:

AxeConf axeConf = new AxeConf()
    .removeStandard(AxeStandard.BEST_PRACTICE);

Targeting Standards

If you have an organizational push to be WCAG 2.0 compliant for example, it can be beneficial to ignore any other rules. The best way to do this would be:

AxeConf axeConf = new AxeConf()
    .removeStandard(AxeStandard.BEST_PRACTICE)
    .removeStandard(AxeStandard.PLATFORM)
    .removeStandard(AxeStandard.WCAG_21);

Notice we removed ALL standards except AxeStandard.WCAG_20.

Avoiding False Positives

We do our best, but we are not perfect. The BEST response when you run into a False Positive is to report it. We are very quick to fix issues in the library.

• Accepted False Positive tickets are the absolute highest priority.
• If we cannot create a 100% false positive free rule, we will demote it to a Best Practice.

HOWEVER, sometimes you cannot wait for a false positive free library. In this case, it is best to remove the associated standard, and add back in any Rules that are working.

AxeConf axeConf = new AxeConf()
    .removeStandard(AxeStandard.WCAG_20)
    .addRule(ImageViewName.class);

Note: We will make this easier in future releases!