Open in app

Sign in

Write

Sign in

Accessibility testing for Android apps — how to start

Artour Bakiev
6 min readMay 16, 2020

--

This short guideline describes what kind of steps you should perform and what you should expect as a developer if you’re going to support accessibility features and services in your Android app but never thought about that before.

Step-by-step guide

Having an accessibility compliant application is not a trivial task but requires a significant effort from both developer and QA teams. Moreover the final steps imply manual verification by accessibility experts and/or by people with disabilities.

But before that final stage takes place certain steps should be performed to address certain type of issues. That might noticeable reduce cost and boost the process.

The process should start with proper static code analysing setup. Then instrumentation test (and probably unit test) should be executed.

Once the steps above are succeeded the application should be scanned in a semi-automated mode.

The very last step is manual testing which is mandatory for accessibility features.

This text mainly is about automated/semi-automated tasks.

1. Lint verification

The first step is to check the project using the lint tool to find any accessibility issues the project might have at the moment. While running lint consider to reduce the validation scope to accessibility issues only. The reason is obvious — it’s just save your time.

At the moment of writing there are five accessibility issues which are verified by lint v 3.2 (http://tools.android.com/tips/lint-checks):

  • ClickableViewAccessibility — Accessibility in Custom Views
  • ContentDescription — Image without contentDescription
  • KeyboardInaccessibleWidget — Keyboard inaccessible widget
  • LabelFor — Missing labelFor attribute
  • GetContentDescriptionOverride — Overriding getContentDescription() on a View

Description for every issue can be found at http://tools.android.com/tips/lint-checks. The fixing process can be found below.

Lint preparation steps

Before running the lint the must have step is to explore your project to see if certain accessibility issues are suppressed at the moment. So you should check:

  • lint.xml — https://developer.android.com/studio/write/lint#pref. Usually located in the root directory of an Android project. Inspect the file and ensure accessibility checks are not suppressed. For first fast and clean check you can just delete the file.
  • lintOptions section in gradle file — https://developer.android.com/studio/write/lint#gradle. Can be in every module. Ensure accessibility checks are not suppressed or just delete the whole section for fast clean run check.
  • lint-baseline.xml — https://developer.android.com/studio/write/lint#customize-the-baseline. Also can be found in any module. It will be used by lint if lintOptions section in gradle file contains baseline command. Ensure the file doesn’t suppress accessibility checks or just delete it as well for the initial clean check.
  • @SuppressLint in *.kt & *.java files. You should perform full text search for the five accessibility issues IDs specified above.
  • //noinspection in *.kt & *.java files. You also should ensure the five accessibility issues IDs are not suppressed.
  • tools:ignore in xml files. The same story — run full text search for the five accessibility issues IDs.

So once you’ve found and removed any suppressions for accessibility issues IDs you are good to go with lint verification.

Running lint

There are two ways to run lint:

  1. Using gradle plugin if you use Android Studio to manage the project or
  2. Using lint command line if you use anything else

The command line way has nice --check switch which allows to specify issue IDs (https://developer.android.com/studio/write/lint#standalone-lint).

Unfortunately if you’re using Android Studio you can’t populate issue IDs to the ./gradlew lint command. So you have to go to Analyze → Inspect Code and create “Inspection profile” by unchecking everything except Android → Lint → Accessibility:

Then run lint inspection for the whole project:

Fix issues found by lint

It makes sense to address every accessibility issue found during previous step. Otherwise there is a high probability next testing steps will reveal these issues again.

The fixing process is rather trivial but could involve copyright team to provide valid labels/descriptions. As a temporary workaround you might want to use a certain string value as a placeholder for ContentDescription and LabelFor accessibility issues. Consider using @null for android:contentDescription decorative images.

The only thing can be tricky is the ClickableViewAccessibility validation. In case onTouchEvent is overridden for swipe action you should analyse the custom widget behaviour to see if it is necessary to trigger performClick or not. If onTouchEvents is overridden to handle a click event just follow guidelines handling custom touch events — https://developer.android.com/guide/topics/ui/accessibility/custom-views.html#custom-touch-events

2. Instrumentation and unit tests

Next step is to integrate accessibility testing into instrumentation Espresso tests if such exist.

First the module build.gradle should be updated to include espresso-accessibility artefact:

dependencies {
    androidTestImplementation "androidx.test.espresso:espresso-accessibility:3.2.0"
}

Then global accessibility verification should be enabled according to https://developer.android.com/guide/topics/ui/accessibility/testing#espresso. You want either to update @BeforeClass method of a test class or to modify your subclass of AndroidJUnitRunner.

@BeforeClass
fun setup() {
    AccessibilityChecks.enable()
}

There is an option to enable accessibility checking applying setRunChecksFromRootView(true) .

@BeforeClass
fun setup() {
    AccessibilityChecks.enable().setRunChecksFromRootView(true)           }

Looks like this option should be preferred comparing to just AccessibilityChecks.enable() because if setRunChecksFromRootView(true) is specified the accessibility framework will validate the entire view hierarchy of a screen.

For unit tests you can also may want to enable Robolectric for accessibility validation. Since accessibility validation is part of the Robolectric artefact first the build.gradle should be updated:

dependencies {
    testImplementation "org.robolectric:robolectric:4.3.1"
}

Then @AccessibilityChecks annotation should be provided for the test class:

@RunWith(RobolectricTestRunner::class)
@AccessibilityChecksclass
MyTest {
}

The result of this step depends on instrumentation tests code coverage for you project.

If the previous step “Lint verification” was done well you shouldn’t expect large number of issues during this phase.

3. Accessibility scanner

The next step is running Accessibility Scanner — https://developer.android.com/guide/topics/ui/accessibility/testing#accessibility-scanner. This step is semi-automated — you should manually specify a screen but the screen is going to be validated automatically.

You have to run the Accessibility Scanner against every screen in your application despite of having complete previous “Instrumentation test” step above. The reason is to cover everything missed:

The complete list of issues reported by the Accessibility Scanner can be found here — https://support.google.com/accessibility/android/answer/6376559. Some of the issues would just duplicate what can be found by lint and by Espresso and Robolectric frameworks but others seems to be unique. So it makes sense to fix or suppress issues found in previous steps before running the Accessibility Scanner.

4. Pre-launch report

You may also want to inspect pre-launch report — https://developer.android.com/guide/topics/ui/accessibility/testing#pre-launch-report. It’s being generated once new version of the app is uploaded to Play Store.

Under the hood it uses the Accessibility Scanner described in the previous step. But since it happens during monkey testing when random screens are shown there is a chance it would report anything missed during step #3.

5. Manual testing

Automation tools should be considered as initial verification steps. Take into account the following:

  • Automated tests can’t detect every potential accessibility issue. For example screen rotation and hover trap issues might not be reported by automation tools
  • Automated tests depend on code coverage

According to experts the manual testing is the must have step. Because the task is specific one the verification should be performed by experts and/or by impaired persons.

References

Android
Accessibility Testing
Accessibility

--

--

Artour Bakiev

Written by Artour Bakiev

2 Followers

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams