Roger accessibility on Android — Part I
At Roger we care deeply about voice communication and our mission to make people talk more often. And that means making sure it reaches everyone in an easy and fun way to use. Good accessibility support means much more than just making sure the app supports screen readers, different fonts sizes and good contrast ratios. It is a learning process, and one in which we ourselves still have much to learn and explore. This article is the first one of a series about application accessibility in which I share some of the fruits from our own research and adaptation for your Roger Android application. The content is focused towards an Android developer’s standpoint although a lot of the the UX suggestions apply to any platform and skillset.
Hi TalkBack! 👋
TalkBack is the default screen reader for Android devices, it comes pre-installed for most devices that bundle Google Apps. Invest some time familiarizing yourself with the many options it offers. Here’s a quick rundown of the ones that I consider most relevant during development.
To access TalkBack options navigate to Settings > Accessibility >TalkBack.
Display speech output
This will make every thing that is spoken read on the bottom part of the screen, similar to the captions in a movie. It is very useful to confirm that you spelled everything correctly when testing the app, and is really useful for displaying navigation on photos such as the ones on this article.
TalkBack screen dimming
Screen dimming places an almost fully opaque black canvas on top of your entire screen for a period of 3 minutes, allowing you to experience the app closer to as a visually impaired user would. You can also enable the “Dim screen shortcut”, that toggles this mode by tapping both volume keys simultaneously 3 times!
TalkBack Tutorial
Last but not least, if you never did so before, you should complete the TalkBack tutorial. First of all to be able to use the phone properly when you enable TalkBack, but most importantly to get a proper sense of what kind of gestures and actions you can perform, it will allow you to create a better experience.
Design for accessibility
A lot can be said about designing for accessibility, I’ll post more about this subject in upcoming articles about accessibility. One thing to always keep in mind, specifically when it comes down to screen readers, is that you’ll effectively end up with 2 very distinct ways of interacting with your application, the one you can see and the one interpreted by a screen reader.
I divided the subject into several sub-topics. By no means is this exhaustive, I tried rather to get you thinking how these 2 different interfaces require different mindsets.
Navigation
Material’s design Metrics and Keylines guide has a lot of focus in providing breathing area for clickable content. If this was advised before, it is then reinforced when it comes to designing for accessibility. It is hard enough for anyone to press small visual elements that are close together, it get’s more frustrating when you don’t perceive the content visually and for people with motor disabilities. So make sure your content follows those guidelines!
When it comes to visually impaired users, and users that use a directional keyboard (sometimes in the form of a physical keyboard) it is important to pay attention to the order in which it is possible to navigate your content and also which areas are relevant.
Group similar content together into one clickable element for TalkBack, although in practice they are two separate TextViews.
Be smart, fun and human! Look how the description alights with the title so that it is reads together in a natural way for TalkBack users ⛰, while remaining visually relevant apart.
TalkBack screen dimming allows you to glimpse into how it would be to use the app as a visually impaired user. Take the information on the bottom part of the card for example. There’s a graphical indication of the weather, and a bunch of other useful information such as the local time of user you’re talking to. Since it all belongs to the same context, make it all one element for TalkBack, and read iconography elements when relevant. Also, while it is visually very easy to glimpse at the screen and know who this information belongs to, the same is not true for TalkBack. Look for ways to making the most relevant information immediately available, such as reading the name of the user you’re talking with again along with the status.
In few words
Be succinct when describing content. Short and direct TalkBack explanations will keep the application interesting and easy to navigate.
As a developer, some things to be aware when designing your layouts:
- Use the “android:hint” attribute for EditText fields instead “android:contentDescription” to explain the purpose of this particular control. TalkBack users have the ability to ignore this hint once they’re familiar with the app, give them that option.
- If a control is clickable and it is not a button, specify the “android:clickable” and “android:focusable” attributes, it helps some screen readers understand the purpose of this content and will for some configurations ring a small *beep* that tells the user this content is clickable.
- For Android KitKat and newer devices leverage the attribute android:accessibilityLiveRegion=”polite” if a given control should be announced to the user as soon as it changes state. But be mindful and don’t overuse it.
Listen to User Feedback
We have an awesome and active Slack beta community where users frequently give us suggestions. But when it comes to TalkBack, the real game changer for us was when we made the decision to incorporate into Roger the possibility for you to speak with a randomly assigned person on the Roger Team. This opened the possibility for us to listen with crystal clear detail the way TalkBack and VoiceOver users interact with the app, their various expectations and allowed me personally to realize so much more about how powerful voice can be in clear communication, the manifestation of feelings and as a tool of personal expression.
Next article will contain further integration with Android’s built-in support for accessibility and more things too look for when designing for visually impaired users. Tell me what you think in the comment’s section below! If you’ve worked with accessibility yourself, your feedback and own learnings are highly appreciated as well :)
Sign up for our Roger newsletter here for more tips and the latest features: 👉🏼 http://bit.ly/rogernewsletter👈🏼
