Accessibility is about making sure that Android users who have limited vision or other physical impairments can use your application just as well as all those folks in line at the supermarket checking email on their phones. According to the research, over 1 billion people live with some form of disability. Therefore, by building more accessible apps, your product can serve a wider variety of users and make life easier for people with disabilities. When building with accessibility in mind, you are also helping users who have situational disabilities. For example, sometimes you might be in a bright outdoor setting where it’s more difficult to see the phone screen. Or you might be in a loud room where it’s harder to hear sounds from your phone.

Accessibility Services available in Android

What exactly are Accessibility Services? Accessibility Services are long-running privilege services that provide an alternate way for users with disabilities to interact with Android devices.

We have three commonly used accessibility services:

• TalkBack
• Switch Access
• Voice Access

TalkBack is commonly used by blind and visually impaired users. When using TalkBack, users discover content by moving their fingers across the device screen. TalkBack announces the views that are under the finger and the user can interact with those views using familiar gestures.

When using Switch Access, a user connects two or more switches to a device. Typically, one switch is used to navigate between the different controls on the screen and the second switch is used to interact with those controls.

When using Voice Access, the user interacts with the screen entirely using voice commands. Both Switch Access and Voice Access remove the assumption that the user can actually touch the screen.

How to Enable TalkBack

To turn on TalkBack, go to Settings on your Android device. Then find Accessibility/TalkBack, and toggle the tool on.

Please refer to these URLs to learn more about using the TalkBack function.

• Navigate your device with TalkBack — Android Accessibility Help
• Use TalkBack gestures — Android Accessibility Help

Checklist for making apps accessible

Here are some key steps for ensuring that your application is accessible:

Design task flows: Design well-defined, clear task flows with minimal navigation steps, especially for major user tasks, and make sure those tasks are navigable via focus controls.

Check action target size: Make sure buttons and selectable areas are of sufficient size for users to easily touch them, especially for critical actions. Google recommends that touch targets be 48dp or larger.

Label user interface controls: Label user interface components that do not have visible text, especially ImageButton, ImageView, and EditText components. Use the android:contentDescription XML layout attribute or setContentDescription()to provide this information for accessibility services.

Enable focus-based navigation: Make sure users can navigate your screen layouts using hardware-based or software directional controls (D-pads, trackballs, and keyboards). In a few cases, you may need to make UI components focusable or change the focus order to be more logical.

Build custom view controls: If you build custom interface controls for your application, implement accessibility interfaces for your custom views and provide text labels for the controls.

Use headings within text: Some apps use headings to summarize groups of text that appear on the screen. If a particular View element represents a heading, you can indicate its purpose for accessibility services by setting the element’s android:accessibilityHeading attribute to true.Users of accessibility services can choose to navigate between headings instead of between paragraphs or between words. This flexibility improves the text navigation experience.

Set the navigation between views: We can set the traversal order for screen readers in the XML

Convey the state for Accessibility: Users of Accessibility Services need to know the state of a view so they can properly interact with that view. For example, they want to know

• Is the button enabled or disabled?
• Is a switch on or off?
• Is a checkbox checked or unchecked?

Typically, screen readers like TalkBack announce a text label for a view along with information about the type and the state of that view.

For custom widgets, icons or badges, there are no such properties. Accessibility services don’t know about our custom volume indicator or microphone badge is on or off, disabled or enabled so it is necessary to bake information about the state into the content description. we can use state description API to set or get a views state description.

In a View-based system, we can use the ViewCompat API from AppCompat. It uses view tags to backport support all the way back to Android 4.4 (API 19)!

A state description should be a localized string, which can be translated into the user’s preferred language.

Handling content that times out: When implementing UI elements that disappear after a set amount of time, we need to follow best practices that will allow all users a chance to interact with the element that times out.

Let’s take a look at an example we have a situation in which snackbar comes and users can swipe left on a task to archive the task. Once a task is archived, a snackbar appears on the bottom of the screen that contains an action to undo the archive action. On default settings, the snackbar automatically disappears after a set amount of time.

Now, let’s consider this flow when using an accessibility service such as TalkBack to interact with the app. When TalkBack is enabled, controls that timeout are not announced unless they are focused on. That means that if the snackbar disappears from the screen too quickly, the user may never be aware that they had the option to undo their previous action. To ensure that the snackbar can be used by everyone, including users of accessibility services, the snackbar widget queries a user’s customization for timeout deviation to determine how long the snackbar should stay visible on the screen. In the Accessibility Settings screen, users can manually set a timeout duration in the Time to Take Action screen. If users don’t change the setting, services like TalkBack may step in with a guess based on the typical needs of their users. Thus, you should take into account the user’s preference for timeout durations when building applications. Starting in Android Q, the accessibility API can be used to query for the customized timeout duration and determine how long to show elements that will eventually time out. Prior to Android Q, if the user is currently using an accessibility service, the element should stay on screen indefinitely until the user dismisses it manually.

Calling accessibilityManager.isEnabled will check to see if any accessibility service, such as TalkBack or Switch Access, is on. The logic to properly handle timeout durations is already built into the snackbar widget, so you don’t have to implement the logic yourself. But for other similar UI elements, such as a tooltip or any other content that times out, you should follow the logic implemented in the snackbar in your own app.

Accessibility Testing Tools

Testing is as important as implementation, so make sure to thoroughly test apps after implementing any accessibility features. This can be done by enabling TalkBack and Explore by touch and trying to navigate your app using only audio feedback and directional controls. Ensure that every control element provides the necessary feedback and that audio prompts are not repetitive and longer than needed.

While using TalkBack and other accessibility tools is helpful for finding accessibility shortcomings, there are a couple of other testing tools provided for developers to help identify accessibility issues.

Lint: The simplest of these is the linter that Google provides. This is enabled by default in Android Studio and will warn you of accessibility issues such as missing contentDescription

Espresso Tests: For more in-depth checks, you can turn on checks in your Espresso tests. Do this by adding the following line to your test or test runner.

Accessibility Scanner: Google also gives us an Accessibility Scanner that you can download from the Play Store. After downloading, the scanner can be turned on in the same Accessibility settings menu you were in before to turn on TalkBack. Navigate to Settings/Accessibility/Accessibility Scanner, and toggle it on.

Pre-launch Report on Google Play: A pre-launch report is automatically generated when you publish an app to closed or open testing. It helps to identify issues proactively before your app reaches users. It includes tests for:

• Stability issues
• Android compatibility issues
• Performance issues
• Accessibility issues
• Security vulnerabilities
• Privacy issues

Use a pre-launch report to identify issues — Play Console Help

Best practices for adding descriptions to your app’s UI elements

• Don’t include the type of UI element in the content description. Screen readers automatically announce both the element’s description and type. For example, if selecting a button causes a “submit” action to occur in your app, the button’s description should be "Submit", not "Submit button".
• Each description should be unique. That way, when screen reader users encounter a repeated element description, they correctly recognize that the focus is now on an element that has already had focus earlier.
• In particular, each item within a view group such as RecyclerView should have a different description. Each description should reflect the content that’s unique to a given item, such as the name of a city in a list of locations.
• If your UI includes graphical elements that are used for decorative effect only, set their descriptions to "@null". If your app’s minSdkVersion is 16 or higher, you can instead set these graphical elements’ android:importantForAccessibility attributes to "no".

References

• Starting Android Accessibility | Android Developers
• Accessibility Specs & Implementation
• Accessibility scanner — Accessibility on Android
• Accessibility on Android

Found this article useful? Follow me (Suchi Bansal) on Medium and check out my other popular articles below!

Android 12 Privacy Changes For Location

Nearby Connection API

How to flip items in Recycler View

This article was originally published on proandroiddev.com on March 24, 2022