• Make custom views more accessible
• Create your own accessibility service

Testing for accessibility lets you experience your app from the user's perspective and find usability issues that you might miss. Accessibility testing can reveal opportunities to make your app more powerful and versatile for all users, including those with disabilities.

For the best results, use all of the approaches described in this document:

Manual testing

Manual testing puts you in the shoes of your user. Android AccessibilityService objects change the way your app's content is presented to the user and how the user interacts with the content. By interacting with your app using accessibility services, you can experience your app as your users do.

TalkBack

TalkBack is Android's built-in screen reader. When TalkBack is on, users can interact with their Android-powered device without seeing the screen. Users with visual impairments might rely on TalkBack to use your app.

Turn on TalkBack

Explore your app with TalkBack

Once TalkBack is on, there are two common ways to navigate:

To explore your app with TalkBack, complete these steps:

For more information and tips, refer to the TalkBack user documentation

Optional: TalkBack developer settings

TalkBack developer settings make it easier for you to test your app with TalkBack.

To view or change developer settings, complete these steps:

Switch Access

Switch Access lets users interact with Android-powered devices using a switch instead of the touch screen. There are several kinds of switches: assistive technology devices such as those sold by AbleNet, Enabling Devices, RJ Cooper, or Tecla*; external keyboard keys; or buttons. This service can be helpful for users with motor impairments.

* Google doesn't endorse these companies or their products.

Turn on Switch Access

One way to configure Switch Access is with two switches. One switch is designated as the "Next" switch and moves focus around the screen, and a second "Select" switch selects the focused element. To use this two-switch method, you can use any pair of hardware keys.

Note: Your experience with Switch Access might vary, depending on the tools and software you use.

To set up Switch Access using the volume down key as the "Next" switch and the volume up key as the "Select" switch, complete the following steps:

Explore your app using Switch Access

To explore your app with Switch Access, complete these steps:

Optional: Use group selection to see all scannable items

Group selection is a Switch Access navigation method that lets you see all scannable items at once. This option lets you perform a quick check to see whether the correct elements on the screen are highlighted.

To turn on group selection, complete these steps:

To explore your app with Switch Access using group selection, complete these steps:

To learn more about how users can navigate with group selection, see Tips for using Switch Access .

Voice Access

Voice Access lets users control an Android-powered device with spoken commands. Voice Access is available on devices running Android 5.0 (API level 21) and higher. To test your app with Voice Access, learn how to get started with Voice Access .

Testing using analysis tools

Analysis tools can uncover opportunities to improve accessibility that you might miss with manual testing.

Compose UI Check

Activate Compose UI Check mode on a Compose Preview to enable Android Studio to automatically audit your Compose UI for accessibility issues. Android Studio checks that your UI works across different screen sizes by highlighting issues such as text stretched on large screens or low color contrast in the problems panel.

Accessibility Scanner

The Accessibility Scanner app scans your screen and suggests ways to improve the accessibility of your app. Accessibility Scanner uses the Accessibility Test Framework and provides specific suggestions after looking at content labels, clickable items, contrast, and more.

The Android Accessibility Test Framework is integrated in Android Studio to help you find accessibility issues in your layouts. To launch the panel, click the error report button in the Layout Editor.

To learn more, refer to the following resources:

Pre-launch report on Google Play

If you distribute your app on Google Play, you have access to a pre-launch report for your app. Google Play generates this report shortly after you upload an app to a release channel using the Google Play Console. The pre-launch report, which is also available in the Google Play Console, displays the results of tests that Google Play performs on your app.

In particular, Google Play runs accessibility tests using the Accessibility Framework . The results of these tests appear in a table on the Accessibility tab of your app's pre-launch report.

The table organizes opportunities for improvement into the following categories:

Following the table, the pre-launch report shows snapshots of your app. These snapshots represent the top opportunities to improve your app's accessibility in each category. Select a screenshot to view more details, including a suggested improvement and a more complete list of places in your app where you can apply the same improvement.

Figure 2 shows an example of the table that appears on the Accessibility tab of a pre-launch report within Google Play. This figure also includes one of the app's snapshots, showing that the Next button has a touch target size that is smaller than recommended.

UI Automator Viewer

The uiautomatorviewer tool provides a convenient GUI to scan and analyze the UI components currently displayed on an Android-powered device. You can use UI Automator to inspect the layout hierarchy and view the properties of UI components that are visible on the foreground of the device. This information lets you create more fine-grained tests, for example by creating a UI selector that matches a specific visible property. The tool is located in the tools directory of the Android SDK.

In accessibility testing, this tool is useful for debugging issues found using other testing methods. For example, if manual testing reveals that a view doesn't have the speakable text it requires or a view receives focus when it must not, you can use the tool to help locate the source of the issue.

To learn more about UI Automator Viewer, see Write automated tests with UI Automator .

Android Studio shows lint warnings for various accessibility issues and provides links to the relevant places in your source code. In the following example, an image is missing a contentDescription attribute. The missing content description results in the following message:

Figure 3 shows an example of how this message appears in Android Studio:

Automated testing

The Android platform supports several testing frameworks, such as Espresso, which lets you create and run automated tests that evaluate the accessibility of your app.

Espresso

Espresso is an Android testing library designed to make UI testing fast and easy. It lets you interact with UI components under test in your app and assert that certain behaviors occur or that specific conditions are met.

To see a video overview of accessibility testing with Espresso, watch the following video from minute 31:54 to 34:19: Inclusive design and testing: Making your app more accessible - Google I/O 2016 .

This section describes how to run accessibility checks using Espresso.

Enable checks

You can enable and configure accessibility testing using the AccessibilityChecks class:

import androidx.test.espresso.accessibility.AccessibilityChecks
@RunWith(AndroidJUnit4::class)
@LargeTest
class MyWelcomeWorkflowIntegrationTest {
    init {
        AccessibilityChecks.enable()
import androidx.test.espresso.accessibility.AccessibilityChecks;
@RunWith(AndroidJUnit4.class)
@LargeTest
public class MyWelcomeWorkflowIntegrationTest {
    @BeforeClass
    public void enableAccessibilityChecks() {
        AccessibilityChecks.enable();
By default, the checks run when you perform any view action defined in
ViewActions. Each
check includes the view on which the action is performed as well as all
descendant views. You can evaluate the entire view hierarchy of a screen during
each check by passing true into
setRunChecksFromRootView(),
as shown in the following code snippet:
Kotlin
AccessibilityChecks.enable().setRunChecksFromRootView(true)
AccessibilityChecks.enable().setRunChecksFromRootView(true);
Suppress subsets of results
After Espresso runs accessibility checks on your app, you might find several
opportunities to improve your app's accessibility that you cannot address
immediately. In order to stop Espresso tests from continually failing because
of these results, you can ignore them temporarily. The Accessibility Test
Framework (ATF) provides this functionality using the
setSuppressingResultMatcher() 
method, which instructs Espresso to suppress all results that satisfy the given
matcher expression.
When you make changes to your app that address one aspect of accessibility, it's
beneficial for Espresso to show results for as many other aspects of
accessibility as possible. For this reason, it's best to suppress only specific
known opportunities for improvement.
When you temporarily suppress accessibility test findings that you plan to
address later, it's important to not accidentally suppress similar findings. For
this reason, use matchers that are narrowly scoped. To do so, choose a
matcher 
so that Espresso suppresses a given result only if it satisfies each of the
following accessibility checks:
Accessibility checks of a certain type, such as those that check for touch
target size.
Accessibility checks that evaluate a particular UI element, such as a button.
The ATF defines several matchers 
to help you define which results to show in your Espresso tests. The following
example suppresses the results of checks that relate to a single TextView
element's color contrast. The element's ID is countTV.
Kotlin
AccessibilityChecks.enable().apply {
        setSuppressingResultMatcher(
                allOf(
                    matchesCheck(TextContrastCheck::class.java),
                    matchesViews(withId(R.id.countTV))
AccessibilityValidator myChecksValidator =
    AccessibilityChecks.enable()
        .setSuppressingResultMatcher(
            allOf(
                matchesCheck(TextContrastCheck.class),
                matchesViews(withId(R.id.countTV))));
User testing
Along with the other testing methods in this guide, user testing can provide
specific and valuable insights about the usability of your app.
To find users who can test your app, use methods such as the following:
Reach out to local organizations, colleges, or universities that provide
training for people with disabilities.
Ask your social circle. There might be people with disabilities who are
willing to help.
Ask a user testing service, such as
usertesting.com, if they can
test your app and include users with disabilities.
Join an accessibility forum, such as
Accessible, and ask
for volunteers to try your app.
For more tips, watch the user testing section of the following video, from
minute 31:10 to 44:51: Behind the scenes: What's new in Android accessibility -
Google I/O 2016.
  
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
  
Last updated 2024-04-30 UTC.
      [[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-04-30 UTC."],[],[],null,[]]