jetpack compose android flying a jetpack to an accessibility symbol

Building Accessible Android Apps with Jetpack Compose: How Accessibility Service Interacts with Jetpack Compose

Google recently came out with Jetpack Compose, a modern Android UI toolkit for building native Android UI faster and easier by using intuitive declarative Kotlin APIs. This means no more XML type of view coding but instead coding views using declarative APIs.

Jetpack Compose gives developers the ability to programmatically generate complex themes and UI components while avoiding the boilerplate that XML requires. With that being said Jetpack Compose comes with its own custom-built accessibility APIs. Here are some advantages of using Jetpack Compose:

  • Faster and easier Android UI development (especially for developers like me!)
  • Intuitive Kotlin APIs
  • Easy to catch bugs in UI
  • Less code (Who doesn’t like that?)
  • Built-in support for Material Design, Dark Theme, and Animation
  • Easy to create reusable UI components.

Imperative or XML type of view building:

Declarative type of view using Jetpack Compose:

In this part of the series, we will learn how Jetpack Compose behaves with Accessibility Service in Android and how it differs from how Imperative or XML type of view interacts with Accessibility Service.

How do Accessibility Services work in Android?

An Accessibility Service is a service in Android that, when turned ON, runs in the background and responds to the Accessibility Events like tap, focus, tap and hold, two finger swipe, swipe right, etc. The screen/window content is arranged in a tree and each node in the tree is represented as an AccessibilityNodeInfo. Each AccessibilityNodeInfo contains information like Name, Role, Value, and Action associated with that particular view.

Image showing how Android Operating System translates a view on screen into an Accessibility Tree and from that tree Assistive Technology gathers data and presents to an Assistive Technology user.

How does the Imperative/XML type UI interact with Accessibility Services?

In Imperative/XML views, the accessibility service tries to gather accessibility-related information by visiting each and every element in the view hierarchy. For example:

For the above button, the Accessibility Service tries to determine what to announce based on the class to which the view belongs, the text on the view (“Show Dialog”), and some more information like boundsInScreen, etc. Finally, the Accessibility Service gathers enough data to announce “Show Dialog, Button, Double Tap to activate.”

How does the Declarative type UI interact with Accessibility Services?

Things are a bit different in Declarative views as compared to Imperative views. Jetpack Compose uses a tree of values outlining the Semantics properties of your views. This makes it easy for the Accessibility Service to determine which data to collect; however, it does not define information on how the composable will be drawn. For example:

A simple button in Jetpack Compose automatically supplies appropriate semantics to the Accessibility Service which contains all the vital information like Name, Role, Value and State of the composable.

For a more customized composable, Jetpack Compose allows the developers to set the semantics manually, for example:

In the example above, the Row is acting like a Button. By setting the Semantics property “role” to button we are telling Accessibility Service to treat this row like a button and add the action “Double Tap to Activate” to it.

As accessibility-related information is collected from each and every element on the screen, it is simultaneously arranged in a tree called the Accessibility Node Info Tree. Jetpack Compose makes it easy for the Accessibility Service to create the Accessibility Node Info Tree because it already maintains a semantics tree.

Image showing how Jetpack Compose translates a User Interface into a Semantics Tree.

Compose allows us to look into the composition hierarchy or the semantics tree, which will be covered in part two of this blog series.

Merged and Unmerged Composition Hierarchy in Jetpack Compose

Jetpack Compose creates two types of composition hierarchies for each composable. Consider a simple compose button:

Image showing a simple Compose Text Button named Text Field Examples.

This is how the above button is coded using declarative APIs:

Jetpack Compose creates two types of semantics composition hierarchy for this button:

Image showing Merged version of semantics composition hierarchy for a simple text button.

Merged Composition Hierarchy

Image showing Unmerged version of semantics composition hierarchy for a simple text button.

Unmerged Composition Hierarchy

Upon closer look, we can see that Unmerged Composition Hierarchy has Text in a separate Node, whereas in Merged Composition Hierarchy, Text is part of the same node.

The important thing to note is that the Accessibility Service gathers information from the Merged Composition Hierarchy. The Unmerged Composition Hierarchy gives deeper insight into how the elements are arranged within the hierarchy, and the Merged Composition Hierarchy gives insight into how the Accessibility Service is going to treat that particular composable.


In part one of this blog series on building accessible android apps with Jetpack Compose, we learned how Accessibility Services in Android interacts with Jetpack Compose as compared to Imperative or XML type of views. In part two, we will learn how to make basic Jetpack Compose elements like Button, Switch, TextField, etc. accessible to Accessibility Technology users using simple real-time code examples, and also we will see how to grab composition hierarchy using automated tests in Jetpack Compose.

Photo of Devanshu Chandra

About Devanshu Chandra

Devanshu Chandra has been an Android Developer since 2016 and with Deque since 2020. He takes a keen interest in teaching Android mobile accessibility to a new generation of developers across the globe, on a need basis he conducts online sessions to teach accessibility. He spoke at axe-con 2021 and has given guest lectures at many schools. Devanshu has been an advocate of Automation and has helped numerous organizations in achieving their automation goals. He is a die-hard Red Wings fan and dreams of Lions winning Super Bowl someday.
update selasa

Leave a Reply

Your email address will not be published. Required fields are marked *