Android Accessibility: A Developers Guide
Tags: android, mobile, a11y, beginners
Published: 2022-12-15 18:42:30

Accessibility in the mobile space has gotten much more attention lately with the increase in accessibility features on Android. More and more users are wanting applications that can properly use all these different assistive technologies such as TalkBack, enlarged font sizes and high contrast mode.

Making the Android applications you develop accessible ensures that it is usable for EVERYONE. However, accessibility in Android development is always seen as a bottle neck that slows down the ability to quickly release updates and features for your application. How can you ensure that all your content is accessible while also maintaining velocity? Let's dive in!

## Follow Accessible Development Practices

There are many ways to ensure that the content you create is accessible as you develop it. One of the best ways is to follow accessible development practices. Let's take a look a few of the top ones! 

### Use Native Elements Over Custom

When developing new content, make use of the native android elements over creating custom elements. When we say native elements here, we are talking about widgets such as Androids <Button/> or <EditText/> (Note: the same goes for JetPack Compose as well). 

These elements come with all the accessibility baked into them from the start and will properly announce the role and purpose of each control. Whereas custom elements, you as the developer have to give it a proper role and ensure it announces properly. 

### Accessible Labels for Inputs/Buttons

When creating any type of text input or actionable item, it must have a proper accessible label associated with it that describes the purpose of the control. If a label is not present, it will simply read as "Unlabeled"  and the purpose of the control will not be known. 

Let's take a look at a couple of examples. First, is icon buttons not being labeled. Developers have a habit of not labeled buttons that do not include visible text, and it makes it impossible to know the buttons purpose. Examples of icon buttons can be seen below: 

![Examples of icons such as volume up, down, settings, hamburger menu](https://m1.material.io/assets/0Bzhp5Z4wHba3Q1N3MVZFU1M5dVE/patterns-actions-fab-qualities2.png)

Another example is text inputs missing labels. Most users think having a simple placeholder will cover, but this is not the truth! You MUST include a proper label for inputs using either `contentDescription` or `labelFor`

``` xml

<TextView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="@string/first_name"
        android:labelFor="@id/first_name" />
    <EditText
        android:id="@+id/first_name"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />

``` 

For more information on accessible labeling see the following:

*  [Labeling Content in Android](https://support.google.com/accessibility/android/answer/7158690?hl=en)
* [Accessibility Labeling in Compose](https://developer.android.com/jetpack/compose/accessibility#semantics)

### Allow for Text Resizing

One of the biggest used assistive technology on Android is resizing of text. Larger fonts are very common with an aging population. However, most applications do not ensure they are making content the allows for text to be properly resized. 

Couple of things can be done to ensure you can properly resize text:

* Instead of pixels (px), use scalable pixels (sp)
* Ensure you are not setting width and height of containers and ensuring the content is wrapped

For more information on accessible labeling see the following:

* [Text Scaling in Android](https://support.google.com/accessibility/android/answer/12159181?hl=en)
* [Text Resizing in iOS/Android](https://www.a11yproject.com/posts/text-resizing-in-ios-and-android/)

### Other Practices

Here some other very simple development practices you can follow in order to make your application more accessible as you develop!

* Ensure decorative images are hidden from TalkBack Users
* Sections of content broken up by headings need the proper `accessibilityHeading` attribute
* Group sections of text in rows together for ease of reading while using TalkBack

## Make Use of Automation

One very simple way to help improve accessibility in your application development is to make use of the various automated options Android has for accessibility. Yes, automation only catches around 25% of the issues and doesn't replace the practices mentioned above or even manual testing, but it does help enforce accessible practices and build a culture of accessibility! Let's take a look at different types of automation that exist! 

### Linting 

Android studio includes a built in linter that allows you to see accessibility issues that exist within your application! This a great feature that truly lets you see the issues your content you create has as early as possible. 
 
![Example of linter that shows content description missing and inaccessible by keyboard](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/30irfyv04d1mu2jpu9ko.png)

More information on [Linting for Accessibility](https://developer.android.com/guide/topics/ui/accessibility/testing#accessibility-scanner)

### UI Automated Testing 

The Espresso testing library includes an accessibility library that runs accessibility checks for the view or component the test is for. This can be easily integrated into your UI testing! 

Behind the scenes it runs the [Accessibility Test Framework](https://github.com/google/Accessibility-Test-Framework-for-Android) that is used consistently across Android studios different automated scans. 

``` kotlin
import androidx.test.espresso.accessibility.AccessibilityChecks

@RunWith(AndroidJUnit4::class)
@LargeTest
class MyWelcomeWorkflowIntegrationTest {
    init {
        AccessibilityChecks.enable()
    }
}
```
Source for code snippet: https://developer.android.com/guide/topics/ui/accessibility/testing#kotlin 

## Take 10 Minutes a Day

Mobile accessibility can be a lot to take in at first. The main strategy given to development teams is to do a week long bootcamp. This only adds to the stigma that accessibility is cumbersome and slows down development.

One piece of advice I have given to development teams is to take literally 10 minutes a day and read or take an online accessibility course. That's it, 10 minutes! Doing just that minimal amount of time a day helps retain information and also help build the knowledge base daily. This will change the approach of how you develop your mobile content I guarantee it!

Here are some of my favorite places to read up on mobile accessibility: 

* [Mobile A11y by Rob Whitaker](https://mobilea11y.com/about-mobile-a11y/)
* [Deque Accessibility for Devs](https://www.deque.com/blog/category/accessibility-resources-for-developers/)
* [A11y Weekly Newsletter](https://a11yweekly.com/)

## Training Resources For Developers

If you are looking for training to do, whether in the 10 minutes a day, or just on your own time there are some very good Android accessibility trainings that exist out there!

* [Android Accessibility Tutorial: Getting Started](https://www.kodeco.com/240-android-accessibility-tutorial-getting-started)
* [Android App Development: Accessibility](https://www.linkedin.com/learning/android-app-development-accessibility)
* [Android Accessibility Series on Youtube](https://youtu.be/_1yRVwhEv5I)


## In Summary

Accessibility does not have to be something that slows down your development day to day. If you use proper accessible coding practices, build the use of automation, and spend some time daily building your knowledge, you can ensure that you applications are much more accessible! 

Is there more than just the above? Absolutely! However, to start building accessibility as part of the culture, you have to take small steps to have big gains!