How to implement Android Accessibility Part 1 — General

Hi, today I will talk a bit about accessibility.

I’ll break into parts; this first part is a little more general (can be used for both mobile and websites), but you’ll see that I’m going to mention the Android universe in some parts.

Accessibility is a somewhat obscure topic for some people because they think it’s complicated to implement or never thought about it.

Relax, I thought it was complicated, and I also didn’t know about accessibility.

Moreover, I kept complicating the life of those who really needed it, without knowing what I was doing, building it “easier to me” (which isn’t, I’ll demonstrate in the following article) and harming a considerable slice of people who use the application.

What is accessibility?

In simple words, create things everyone can use.

Let me put myself as an example: I can see the screen well, and I can perform the touch accurately, but a considerable slice of users cannot do that.

Whenever we begin the planning with the business team together with the UX/UI even before the start of development, we have to think that the application we are making isn’t made just for us. We want to reach as many users as possible.

We can use mobile and websites accessibility in at least 5 cases that I can remember.

• Deaf and Hearing Impaired

• Motor disabilities

• cognitive impairments

• blindness and visual impairment

• Illiteracy -> In none of Google’s videos or documents makes its mention. But I know this from experience. There is a slice of illiterates in many countries, and we also have to think about this public. But don’t worry, there’s no need to build something in particular. We’ll use the same precautions to improve accessibility in general (This public uses Talkback to read the screen.)

We must also not forget that we may need accessibility temporarily:

• If we have an accident and we need to plaster our arm or hand

• A surgery

• Or even the sun hitting your mobile screen and you can’t see sharply because of the brightness and clarity.

Android Tools:

There are three tools that Google gives to us to help us with accessibility in Android.

Talkback -> The TalkBack screen reader speaks text and image content on your screen. On your Android device, you can turn this setting on or off.

https://support.google.com/accessibility/android/answer/6007100?hl=en

Brailleback -> With BrailleBack, you can connect a refreshable braille display to your Android device via Bluetooth. In addition, BrailleBack works with the TalkBack screen reader to provide a combined speech and braille experience.

As you use BrailleBack, screen content appears on your braille display, and you can navigate and interact with your device using the keys on display. You can also input text using the braille keyboard.

https://support.google.com/accessibility/android/answer/3535226?hl=en

Switch Access -> Switch Access lets you interact with your Android device using one or more switches instead of the touchscreen. Switch Access can be helpful if you can’t interact directly with your device.

https://support.google.com/accessibility/android/answer/6122836?hl=en

What motivates me to study accessibility?

It wasn’t my initiative. It was a client’s need I served. The client in question is one of the largest banks in Latin America and fits a wide range of clients.

In Android, the fragmentation of different devices makes any initiative involving accessibility an even more arduous task.

However, when I saw a blind using the app I had just helped develop at the end of the project, it was an enormous satisfaction. Being a part of that was something special for me.

If nothing I’ve written just now motivates you to create your app or website accessibly, I believe this will:

Unfortunately, 1/7 of the global population has some disability.

That fraction equates to over 1 billion people who need to use accessibility when I wrote this article. It equates to approximately 15% of your audience share, which may be not using your app or not using it simply because your application doesn’t support accessibility.

A lot of companies use a 2%~4% to stop supporting older Android versions.

Reflect on this for a moment and see how much it affects your business.

It’s essential to be work together with the business and UX/UI to build solutions achievements. However, it requires studies, planning before reaching development. Otherwise, the rework can be substantial, and it’ll place this audience in the “impossible to do” slice.

The following articles will be:

0 —I̶n̶t̶r̶o̶d̶u̶c̶t̶i̶o̶n̶ ̶t̶o̶ ̶m̶o̶b̶i̶l̶e̶ ̶a̶c̶c̶e̶s̶s̶i̶b̶i̶l̶i̶t̶y̶

1 — How to install the accessibility feature in the emulator (which doesn’t come by default)

2 — What is the correct way to build buttons. (It seems to be a silly and straightforward theme, but there are some details that we don’t take care of in the construction of our screens)

3 — Lists and why not use the build manual with Viewgroups (This can become a nightmare for those who need accessibility if not built correctly)

4 — Automated tests for accessibility (I have no idea how to do it, but I will study)

5 — Jetpack Compose with accessibility (same as item 4)

If you want to know more about the topic, check the link below. https://developer.android.com/guide/topics/ui/accessibility

I hope you enjoyed it, and I really wish I managed to convince at least one reader how important accessibility is to our end customers.

PS.: Special thanks to Gustavo Freitas for the help me to fix my glitches and typos. ;)