Implementing accessibility in Jetpack Compose
As we build Android applications, we need to always have accessibility in the back of our minds because this makes technology inclusive and ensures all people with special needs are considered as we build applications.
Accessibility should be a team effort. If well handled, the advantages include having more people using your application. An accessible application is better for everyone. You also reduce the risk of being sued.
There are different types of disabilities, such as visual, aural, and motor impairments. If you open your Accessibility settings, you will see the different options that people with disabilities use on their devices.
Getting ready
Like previous recipes, we will continue using our sample project from previous recipes; you do not need to install anything.
How to do it…
For this recipe, we will describe the visual elements, which are very vital:
- By default, when we add an
Image
function, you might notice that it has two parameters, a painter for the image and a content description to visually describe the element:Image(painter = , contentDescription = )
- When you set the content description to
null
, you indicate to the Android framework that this element does not have an associated action or state. So, let’s go ahead and update all our content descriptions:Image( modifier = modifier painter = painterResource(city.imageResourceId), contentDescription = stringResource(R.string.city_images)) )
- Make sure you add the string to the
string
res
folder:<string name="city_images">City Images</string>
- So, go ahead and ensure you add a content description for every image that requires it.
- In Compose, you can easily indicate whether a text is a heading by specifying this in the modifier and using semantics to show that that is a heading. Let’s add that in our decorated text:
... modifier = Modifier .padding(18.dp) .semantics { heading() } ...
- Finally, we can go ahead and compile, run, and test whether our application is accessible by following this link on how to manually test using talkback or using automated testing: https://developer.android.com/guide/topics/ui/accessibility/testing.
How it works…
Jetpack Compose is built with accessibility in mind; that is to say, material components such as RadioButton
, Switch
, and so on have their size internally set, but only when these components can receive user interactions.
Furthermore, any screen element that users can click on or interact with should be large enough for reliable interaction. A standard format sets these elements to a size of at least 48dp
for width
and height
.
For example, Switch
has its onCheckChanged
parameter set to a non-null value, including width and height of at least 48dp
; we would have CheckableSwitch()
, and NonCheckableSwitch()
:
@Composable fun CheckableSwitch(){ var checked by remember { mutableStateOf(false) } Switch(checked = checked, onCheckedChange = {} ) } @Composable fun NonCheckableSwitch(){ var checked by remember { mutableStateOf(false) } Switch(checked = checked, onCheckedChange = null ) }
Once you have implemented accessibility in your applications, you can easily test it by installing analysis tools from the Play Store – uiautomatorviewer
and lint
. You can also automate your tests using Espresso or Roboelectric to check for accessibility support.
Finally, you can manually test your application for accessibility support by going to Settings, then to Accessibility, and selecting talkback. This is found at the top of the screen; then press On or Off to turn the talkback functionality on or off. Then, navigate to the dialog confirmation, and click OK to confirm permission.
There’s more…
There is more regarding accessibility that developers should consider as they build their applications, including a state with which they should be able to notify their users on whether a Switch
button has been selected. This ensures their applications support accessibility and are up to standard.