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.
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.
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 | ✅ |
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.
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
- Fix the false positive.
- Demote it to
Experimental
. - 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.
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:
- Implement abstract interfaces.
- Track the Event Stream.
- Build AxeContext, AxeConf, and AxeImage data.
- Run axe and consume results.
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.
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.
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.
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.
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.
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));
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.
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);
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);
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
.
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!