[MUSIC PLAYING]
SHAILEN TULI: This DevByte explains
how you can use custom accessibility actions to make
your apps more accessible.
An accessibility action allows you to add some information
to a view that lets an accessibility service perform
in action on behalf of the user.
At its heart, an accessibility action consists of two things--
a label and a block of code that corresponds to that label.
That's it.
An accessibility service like TalkBack or Switch Access
then finds a standardized way to service that action to the end
user.
In an earlier DevByte in this series,
we talked about the Android Accessibility Model.
Let's recap that.
An app typically presents content to a user, who
interacts with that app by performing actions
like flicking, long pressing, et cetera.
Users with accessibility needs benefit
from having that information presented in multiple ways.
They also benefit from having multiple ways
to interact with your app.
And Accessibility Services provide alternate ways
to present information to users, and it
lets them interact with your app in ways that make
the most sense to their users.
For most situations, if you use standard built-in components,
the Android framework will take care
of interacting with the Accessibility Services for you.
Some actions are built into the widgets and views
that you're familiar with.
So for example, when a TalkBack user focuses on a button,
TalkBack would tell that user how to perform a click.
It'll say, double tap to activate.
And how to long press, double tap and hold for long press.
And if the user picks one of those options,
TalkBack will perform the correct gesture
on behalf of the user.
Other Accessibility Services will
present these familiar actions in different ways
that makes sense to their end users.
In this DevByte, we'll focus on how you can implement logic
related to custom actions, basically
ways in which users can interact with your apps
beyond simply clicking and long pressing.
For example, they could swipe on an item,
drag an item up or down a list, pinch
to zoom an image, et cetera.
These are pretty common ways in which users interact with apps.
And you learn how to use custom accessibility actions to make
these types of interactions work for users
with disabilities who may be using an accessibility service.
OK, let's make all of this concrete
and look at an example from the Tasks Tracker app
that we've been using in these DevBytes.
It has a bunch of features that are commonly
found in many apps.
Let's focus on one feature in particular,
where users can swipe to archive a task.
Now, what about users who cannot actually perform the swipe
gesture?
How do they get to archive a task?
Think of a TalkBack user who cannot see the screen
and relies on spoken feedback to use your app.
This is what a TalkBack user hears when they focus
on a task on the Task screen.
Notice that there's nothing there
about how to archive a task.
Or consider the Switch Access user
who may not be able to touch the screen at all,
and may be relying on a couple of switches
to interact with the device, with one switch being used
to discover the interactive items
on the screen and the other switch
to interact with an item.
This is what a Switch Access user experiences
when they focus on a task.
Again, there's no way for the end user to archive a task.
This is where Custom Accessibility Actions come in.
You specify a label, then associate
that label with some code that you've probably
already implemented, and Accessibility Services
like TalkBack and Switch Access will
find a way to service that functionality to the end user.
OK, let's improve that swipe to archive feature a little bit.
You've already implemented this feature.
And when a user performs a swipe gesture,
you already run some code that archives a task.
To make this functionality available to users
of Accessibility Services, you use
ViewCompat's addAccessibilityAction method
and you provide the following-- the view to which the custom
accessibility action is attached,
the action label, and the code to execute.
That's it.
All you have to do now is to call addAccessibilityAction
and connect a label, say "archive," and link that label
to the code you already wrote for archiving a task.
And that's it.
OK, so how does this work for a TalkBack user?
TalkBack announced this content about the tasks before,
but this time, it informs the user
that there are actions associated with this task.
And when the user opens the Actions menu,
the archive label is announced to that user.
And when the user chooses that action, the task is archived.
And how does this work for a Switch Access user?
Let's find out.
As before, the user can navigate to each interactive element
on the screen.
However, this time they are also presented with an Actions menu,
and the Archive option is presented to them.
And when the user chooses that action, the task is archived.
Note that for actions to work in Switch Access,
the auto-select option must be turned off.
If it is turned on, the Actions menu will not be displayed.
Instead, clicking on the focused item
will automatically select that item
and perform the equivalent of the click gesture.
OK, to summarize, you can implement Custom Accessibility
Actions using the Android X ViewCompat library.
An accessibility action allows Accessibility Services
to perform an action on behalf of the user.
An accessibility action consists of two things--
a label, and a block of code that corresponds to that label.
You can implement custom accessibility actions
to make your apps more accessible to users
of Accessibility Services.
Thank you for listening.
[MUSIC PLAYING]