Accessibility in Android

Published: at 10 min read

Table of content

What is Accessibility in Android

Accessibility in Android refers to the set of features and tools provided by the Android operating system to ensure that mobile devices are usable by individuals with disabilities.

Android’s accessibility features are designed to make smartphones and tablets more inclusive and user-friendly for people who have various physical, sensory, or cognitive impairments.

Thinking deeper about accessibility in general will also help to build better UI, which will be a good thing for all the users.

Common Accessibility Concepts

  1. Providing appropriate labels for UI elements.
  2. Ensuring proper color contrast so user can easily read text and identify icons
  3. Providing sufficiently large touch targets so that users can interact.

Overview of Accessibility in Android

In Android R version, going deep into the Settings screen

accessibilityOne

accessibilityTwo

accessibilityThree

Accessibility Service and the Accessibility Model

Accessibility Services ~ are long running privilege services that provide an alternative way for users with disabilities to interact with Android devices. It can be think of as plug-ins that change the way the UI works on a device for the user.

  1. TalkBack - commonly used by blind and visually impaired users. When using TalkBack, users discovers content by moving their fingers across the device screen and TalkBack announces the views and users can interact with those view using familiar gestures. It removes the assumption that the user can see but leans into theirs ability to hear and touch the screen with precision.

  2. Switch Access - When using this, 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.

  3. Voice Access - The user interacts with the screen entirely using voice commands.

Both Switch Access and Voice Access remove the assumption that user can actually touch the screen.

Android Interaction Model ~ Android’s accessibility interaction model is designed to ensure that users with a wide range of disabilities can effectively use and interact with the device’s interface and applications.

App with standard views, and majority of the time, these views will present information and allow users to perform actions using Android framework’s or by default Accessibility Services of choice with little effort on the app development part.

Example of Interacting with Toggle Switch in android app with TalkBack, it gives ->

In Some cases, android framework does not able to read out the label of the widgets/components. There, it is important to add “Content description” in the form of localized string and that will describe to purpose of the widget/component.

Making apps more accessible

1.Increase text visibility ~

  1. Use large, simple controls ~

Example of Touch target area :

<ImageButton ...
    android:paddingLeft="4dp"
    android:minWidth="40dp"
    android:paddingRight="4dp"

    android:paddingTop="8dp"
    android:minHeight="32dp"
    android:paddingBottom="8dp" />
  1. Describe each UI element ~

For each UI element in any app, include a description that describes the element’s purpose. In most cases, one should include this description in the element’s contentDescription attribute.

<!-- Use string resources for easier localization. -->
<!-- The en-US value for the following string is "Inspect". -->
<ImageView
    ...
    android:contentDescription="@string/inspect" />

Points to be noted :

Principles to Improve Accessibility

To help people with accessibility needs use any app successfully, One app must follow the best practices.

  1. Label elements - Users must be able to understand the content and purpose of each interactive and meaningful UI element within the app.

    • Editable Elements - When labeling editable elements, such as EditText objects, it’s helpful to show text that gives an example of valid input in the element itself. In the below example, the attribute android:hint will do the work.
    <!-- The hint text for en-US locale would be
 "Apartment, suite, or building". -->

<EditText
android:id="@+id/addressLine2"
android:hint="@string/aptSuiteBuilding" ... />
    • Pairs of elements where one describes the other - It’s common for an EditText element to have a corresponding View object that describes what users must enter in the EditText element. One can indicate this relationship by setting the View object’s android:labelFor attribute.
    <!-- Label text for en-US locale would be "Username:" -->
<TextView
android:id="@+id/usernameLabel" ...
android:text="@string/username"
android:labelFor="@+id/usernameEntry" />

<EditText
android:id="@+id/usernameEntry" ... />

<!-- Label text for en-US locale would be "Password:" -->
<TextView
android:id="@+id/passwordLabel" ...
android:text="@string/password
android:labelFor="@+id/passwordEntry" />

<EditText
android:id="@+id/passwordEntry"
android:inputType="textPassword" ... />
    • Elements in a collection - When adding labels to the elements of a collection, each label must be unique. This way, the system’s accessibility services can refer to exactly one on-screen element when announcing a label.
    data class MovieRating(val title: String, val starRating: Integer)

class MovieRatingsAdapter(private val myData: Array<MovieRating>):
    RecyclerView.Adapter<MovieRatingsAdapter.MyRatingViewHolder>() {

class MovieRatingViewHolder(val ratingView: ImageView) :
        RecyclerView.ViewHolder(ratingView)

override fun onBindViewHolder(holder: MyRatingViewHolder, position: Int) {
    val ratingData = myData[position]
    holder.ratingView.contentDescription = "Movie ${position}: " +
            "${ratingData.title}, ${ratingData.starRating} stars"
    }
}

    • Groups of related content - If the app displays several UI elements that form a natural group, such as details of a song or attributes of a message, arrange these elements within a container, which is usually a subclass of ViewGroup.

      1. Set the container object’s android:screenReaderFocusable attribute to true,
      2. and each inner object’s android:focusable attribute to false.

      This way, accessibility services can present the inner elements’ content descriptions, one after the other, in a single announcement.

      Note: On Android 4.4 (API level 19) and lower, the android:screenReaderFocusable attribute isn’t available, so set the container’s android:focusable attribute instead.

    <!-- In response to a single user interaction, accessibility services announce
 both the title and the artist of the song. -->
<ConstraintLayout
android:id="@+id/song_data_container" ...
android:screenReaderFocusable="true">

<TextView
    android:id="@+id/song_title" ...
    android:focusable="false"
    android:text="@string/my_song_title" />
<TextView
    android:id="@+id/song_artist"
    android:focusable="false"
    android:text="@string/my_songwriter" />
</ConstraintLayout>

    • Headings within text - If a particular View element represents a heading, one can indicate its purpose for accessibility services by setting the element’s android:accessibilityHeading attribute to true.

    • Accessibility pane titles - In Android 9 (API level 28) and higher, one can provide accessibility-friendly titles for a screen’s panes. For accessibility purposes, a pane is a visually distinct portion of a window, such as the contents of a fragment. To specify the title of a pane, use the android:accessibilityPaneTitle attribute.

    <!-- Accessibility services receive announcements about content changes
 that are scoped to either the "shopping cart view" section (top) or
 "browse items" section (bottom) -->
<ShoppingCartView
    android:id="@+id/shoppingCartContainer"
    android:accessibilityPaneTitle="@string/shoppingCart" ... />

<ShoppingBrowseView
    android:id="@+id/browseItemsContainer"
    android:accessibilityPaneTitle="@string/browseProducts" ... />

  2. Add accessibility actions - It’s important to allow users of accessibility services to easily perform all user flows within the app.

    • Make all actions accessible - For actions associated with gestures such as drag-and-drop or swipes, the app can expose the actions in a way that is accessible to users of accessibility services.

    For example, if the app allows users to swipe on an item, one can also expose the functionality through a custom accessibility action, like this:

    ViewCompat.addAccessibilityAction(
    // View to add accessibility action
    itemView,
    // Label surfaced to user by an accessibility service
    getText(R.id.archive)
    ) { _, _ ->
    // Same method executed when swiping on itemView
    archiveItem()
    true
}

    • Make available actions understandable - When a view supports actions such as touch & hold, an accessibility service such as TalkBack announces it as “Double tap and hold to long press.” This generic announcement doesn’t give the user any context about what a touch & hold action does.

      To make this announcement more descriptive, one can replace the accessibility action’s announcement like below example. This results in TalkBack announcing “Double tap and hold to favorite,” helping users understand the purpose of the action.

    ViewCompat.replaceAccessibilityAction(
// View that contains touch & hold action
itemView,
AccessibilityNodeInfoCompat.AccessibilityActionCompat.ACTION_LONG_CLICK,
// Announcement read by TalkBack to surface this action
getText(R.string.favorite),
null
)

  3. Extend system widgets -It’s easier to extend these system-provided widgets than to create your own widget from the more generic View, ViewCompat, Canvas, and CanvasCompat classes.

    • **Define custom events -**When one extends a system widget, one likely change an aspect of how users interact with that widget. It’s important to define these interaction changes so that accessibility services can update the app’s widget as if the user interacts with the widget directly.

    A general guideline is that for every view-based callback one can override, and also need to redefine the corresponding accessibility action by overriding

    ViewCompat.replaceAccessibilityAction()

    One can validate the behavior of these redefined actions by calling

    ViewCompat.performAccessibilityAction()

Practice : CodeLab example of Android app accessibility

Final Takeaway

The Accessibility features and tools make Android devices more inclusive and user-friendly for a broad range of users. They aim to ensure that people with disabilities can independently and effectively use their Android smartphones and tablets to access information, communicate, and perform tasks in their daily lives. Android’s commitment to accessibility aligns with broader goals of promoting digital inclusion and ensuring that technology is accessible to everyone.

Share :
Written by:Parita Dey

Interested in Writing Blogs, showcase yourself ?

If you're passionate about technology and have insights to share, we'd love to hear from you! Fill out the form below to express your interest in writing technical blogs for us.

If you notice any issues in this blog post or have suggestions, please contact the author directly or send an email to hi@asdevs.dev.