
Modern Android 13 Development Cookbook
By :

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.
Like previous recipes, we will continue using our sample project from previous recipes; you do not need to install anything.
For this recipe, we will describe the visual elements, which are very vital:
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 = )
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)) )
string
res
folder:
<string name="city_images">City Images</string>
... modifier = Modifier .padding(18.dp) .semantics { heading() } ...
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 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.