Chapters
Chapters

Chapters

Hide chapters

Android Accessibility by Tutorials

Second Edition · Android 12 · Kotlin 1.6 · Android Studio Chipmunk

Before You Begin

Section 0: 4 chapters
Show chapters Hide chapters

Section I: Android Accessibility by Tutorials

Section 1: 13 chapters
Show chapters Hide chapters

Section II: Appendix

Section 2: 1 chapter
Show chapters Hide chapters

10. Robust
Written by Tori Gonda

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

People use their devices in many different ways, so you need to make sure your app is compatible with accessibility services.

While much of the work happens automatically or is trivial to implement, you need to put in effort for custom views. That’s the main focus of this chapter.

You’ve explored perceivable, operable and understandable. That means you’ve reached the final pillar of the WCAG guidelines: Robust.

Robust: Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.

A robust app is one that people can access in various ways, including with different assistive technologies, such as screen readers.

Android does a lot of the heavy lifting by providing components with built-in support. And it provides an interface for you to leverage. In this chapter, you’ll learn how to use these built-in tools to improve your apps by providing more information about views.

Success Criterion 4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

Level A

This criterion may sound daunting. And you’re not wrong. However, this chapter will give you the insights and practice you need.

You can either work on the starter project for this chapter or continue with the project you used earlier in the book.

Relying on System Views

The simplest way to satisfy the success criterion is by using the views that Android provides. They typically include everything — or almost everything — you need to inform accessibility services about a view’s role and content.

In other words, if you can use a system view instead of creating a custom view, do that! You can customize it; for example, if you need a custom button, you extend the Button rather than starting from scratch with a View.

In Taco Tuesday, you can take advantage of a system view to improve the recipe details screen. There’s a Made it checkbox that is currently two different views: the label and the check box.

Made recipe checkbox.
Made recipe checkbox.

Turn on TalkBack, run the app and observe how this view behaves with the screen reader.

You must highlight them separately. There’s no indication that the checkbox belongs to the “Made recipe” label.

Made recipe TalkBack reading.
Made recipe TalkBack reading.

You can improve this by including the text of the label as part of the checkbox.

Open fragment_recipe_detail.xml. Delete the label:

<TextView
 android:id="@+id/recipe_detail_made_it_label"
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:text="@string/recipe_detail_made_recipe" />

You’re deleting the old view because you’ll combine these views,

You also need to delete references to this label in the Kotlin code:

  1. Open RecipeDetailFragment.kt.
  2. Delete the recipeDetailMadeItLabel.visibility = View.VISIBLE line in showEditableFields().
  3. Delete the recipeDetailMadeItLabel.visibility = View.GONE line in hideEditableFields().

Then, in fragment_recipe_detail.xml, add the text of the label to the CheckBox with ID recipe_detail_made_it:

android:text="@string/recipe_detail_made_recipe"

Now, the CheckBox owns the label and can inform the accessibility services about the associated label.

Build and run. Use TalkBack again and notice that the checkbox is correctly labeled.

Made recipe checkbox with updated TalkBack.
Made recipe checkbox with updated TalkBack.

To make stylistic changes to the CheckBox or any other view, modify or extend the CheckBox itself. Don’t create something new. Using existing views allows you to leverage Android’s built-in support for assistive technologies.

Indicating a View’s Role

Although the system’s components will support most accessibility services without any intervention, you may need to make adjustments to achieve the desired experience. In many cases, you can use an accessibility delegate to make these modifications.

Experimenting With Delegates

Next, you’ll experiment with a delegate for the banner that displays across the top of the screen.

XemfDapn noerers yajpex zayi.
NuhwBapy liafagm gicyip wewi.

Building Custom Views

Custom views can become incredibly complex with different touch areas, actions and behaviors. You need to communicate this complexity to the accessibility services. To make your task a little trickier, documentation around these use cases is a bit…sparse.

Wetxa itt hjodi zapogd lacg.
Fujpu ajv hjosa wayuhw muvj.

Kelepz xoq TifhBogj ruqafqeif.
Layivc yet MowrVoqn ronarboas.

Using ExploreByTouchHelper

If you research how to create these virtual views, you’ll find many options. This chapter will teach you how to use an ExploreByTouchHelper, a type of accessibility delegate that can help you define touch areas.

Defining Virtual Views

The first things you’ll define are:

Performing Actions

Finally, when someone initiates a click action, regardless of if it was with a physical tap or through an accessibility service, you need to add logic to handle it correctly.

Linking the View and Delegate

Now you’re ready to hook up the delegate that defines your virtual views to your custom view.

FeyjLajw genbi bewicv zuyictoug.
CupcXayg quwko maxezp caderkiir.

Improving the State

When using TalkBack, you can’t discern a recipe’s current rating or know when it changes. This diminishes the experience, so you’ll set the content description to the current rating when a user rates a recipe.

Nanjevl doyizf ejgietbok.
Dipkoww pemamz ecvaicsum.

Seeing Service Limitations

While working through this book, you might have noticed that different devices and Android builds support different accessibility services. The differences go deeper than that.

Challenges

Challenge 1: Fix the Rating Bar

The rating bar is editable when on the details screen and not editable when in the list view.

Key Points

  • A robust app is one that integrates with accessibility services.
  • System views are the most reliable way to support accessibility across devices.
  • An accessibility delegate is one of the ways to communicate details to accessibility services.
  • Use ExploreByTouchHelper to create and manage virtual views when a custom view has multiple touch targets.
  • Accessibility services often behave differently on different devices.
  • Android is making continuous improvements to accessibility services.
9. Understandable
11. Designing for Neurodiversity
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now