[MUSIC PLAYING]
SHAILEN TULI: In a previous episode
of this series on Android Accessibility,
you explored the content of the accessibility settings theme
on your phone, and you learned how different users, who
may be deaf or hard of hearing, have motor impairments,
or who may be blind or visually impaired,
modify the default configuration of an Android device
so that they can actually use that device.
In our survey of the accessibility settings screen,
we came across TalkBack, Switch Access, and Voice Access.
These are commonly used Accessibility Services.
And in this talk, you'll learn more
about how these services help many users with disabilities
interact with apps that you've built.
So, what exactly are Accessibility Services?
Let's explore that first.
Accessibility Services are long running privilege services
that provide an alternate way for users with disabilities
to interact with Android devices.
Or, if you prefer, you can think of them
as plug-ins that change the way the UI works
on a device for the user.
TalkBack is commonly used by blind and visually impaired
users.
When using TalkBack, users discover
content by moving their fingers across the device screen.
TalkBack announces the views that are under the finger
and the user can interact with those views using
familiar gestures.
TalkBack removes the assumption that the user
can see, but leans into their ability to hear and touch
the screen with precision.
When using Switch Access, a user connects two or more switches
to a device.
Typically, one switch is used to navigate
between the different controls on the screen
and the second switch is used to interact with those controls.
When using Voice Access, the user
interacts with the screen entirely using voice commands.
Both Switch Access and Voice Access
remove the assumption that the user can actually
touch the screen.
So, what does all this mean for you, the app developer?
Do you have to write multiple versions of your app, one
for users who aren't using any assistive technology, one
for TalkBack users, another for Switch Access users,
yet another for Voice Access users, and so on?
Fortunately, you don't.
Accessibility on Android is easier than that.
You write just one app and the framework
takes care of providing the information needed
by different Accessibility Services
so that end users can properly use your app.
OK, I admit that sounds a little magical.
How does this all work?
Let's talk about Android interaction model.
When a user interacts with the device,
you can divide all interactions as, one, the device presenting
information to the user, showing things like text, buttons,
images, et cetera, and two, the user performing actions
on the device, like pressing buttons, swiping,
scrolling, et cetera.
The user's actions cause more information
to be presented in response and the cycle continues.
Users with accessibility needs benefit
from having that information presented in different ways
and having alternate methods of interacting with your apps.
Remember, you don't talk directly
to each accessibility service.
Instead, you write just use one app,
and the Android Framework communicates
with the Accessibility Services for you.
Most of the time, if you're using standard views,
like text views and buttons, they are built to support
accessibility out-of-the-box.
This means that the majority of the time, these standard views
will present information and allow users to perform actions
using their Accessibility Services of choice
with little effort on your part.
Here's an example of interacting with the switch using TalkBack.
As you're using TalkBack, you move
to different elements of the screen
and there's some text read out to these.
For this switch, TalkBack reads, also vibrate for calls, off,
switch, double tap to activate.
So, it gives you four things.
One, the label, two, the state of the control, three,
the control type, and four, the action
to interact with that control.
This is presented in a pretty standardized way
that TalkBack users are familiar with.
And when I double tap anywhere on the screen,
TalkBack replies on.
For standard widgets, like switches, all this
comes for free.
Now, there are some situations where the framework can't just
automatically tell TalkBack what to say.
Images are a good example of this.
The framework won't know how to interpret these three lines
and explain this fab to the user.
So, it will say something unhelpful,
like unlabeled button.
So, sometimes, you need to fill in the gaps like this
for the accessibility framework, and you do that
by using accessibility APIs.
In this case, you would add the content description,
in the form of a localized string, that would describe
the purpose of the button.
With that in place, the framework
will relay that information to the different Accessibility
Services, who can then service it to the end user.
In the course of this series, we'll
look at different accessibility APIs
that you can use to provide functionality
for end users who are interacting with your apps
using different Accessibility Services.
OK, let's summarize.
In this Tech Byte, you've discovered a high level
view of how accessibility works in Android.
You've seen how users interact with your apps
in different ways, and often by the use of Accessibility
Services.
You've discovered that most build-ins work
for accessibility by default. And you've
learned that sometimes you have to use accessibility APIs
to help the framework the way your app semantics
to the end user.
Thanks for watching, and stay tuned for more videos.
[MUSIC PLAYING]