[MUSIC PLAYING]
SPEAKER 1: In this DevByte we'll discuss
how to convey state from an accessibility perspective.
Users of Accessibility Services need
to know the state of a view so they can properly
interact with that view.
For example, they want to know is
the button enabled or disabled?
Is a switch on or off?
Is a checkbox checked or unchecked?
And so on.
When working with common controls and built-in views,
you mostly don't have to worry about conveying the view
state to the user since this is already done for you.
Typically, screen readers like TalkBack
announce a text label for a view along with information
about the type and the state of that view.
For example, if an interface has a checkbox element,
the screen reader determines whether the element is checked
and announces checked or not checked along with the text
label that you provided.
You should not add checkbox state to the text label.
If you include checked or not checked
in that label the user might hear this information twice,
so avoid doing that.
But sometimes you want to do something custom
and you want to convey the state of a control to the end user.
Example, you've built a star on Star Widget,
say for bookmarking or starring an item in a list,
and you want to tell the user whether it is currently
starred or unstarred.
Enter the state description API.
You can use this API to set or get a views state description.
A state description is a string that should succinctly
describe the state of a view.
This information can then be used by Accessibility Services
who can best determine how that state should
be presented to the end user.
For example, for the Star Unstar widget,
an accessibility service like TalkBack could announce
starred or unstarred, followed by double tap
to toggle to tell the user the current state
of the widget and the action that user
must take to change that state.
A state description should be a localized string,
which can be translated into the user's preferred language.
It should be clear so users understand what is happening,
but also brief so users can efficiently
learn about the view state without listening
to a lengthy announcement.
You are no doubt familiar with the content description
attribute on a view.
So how is a content description different
from a straight description, you're probably wondering.
Simply put, a state description changes frequently
while a content description remains mostly unchanged.
Let's make this clear with a couple of examples.
If you want to describe a static image or an image button,
use a content description.
If you have a widget that shows the sign-in status of a user,
use a state description.
The sign-in status changes, after all.
In the Tasks Tracker app that we've been using in the DevByte
series, we decided that when a TalkBack user focuses
on a single task in a list of tasks,
we would consolidate that task's description
into one single announcement.
We set the start status using the state description
API since a user can toggle the start status while exploring
the list of tasks.
And for other fields, like the task description, the assignee,
et cetera, we use the content description
API since these fields don't change in a list context.
TalkBack or another accessibility service
will combine the state description and the content
description in a way that it feels best helps the user.
In some versions of TalkBack, the end user
could even configure the order of those announcements.
You, the developer, should generally not
try to coerce a particular order.
Let the accessibility service figure
out best how to convey your view's content and state
to the user.
I should mention that there are some APIs that
can [? read ?] state without strings, like set enabled
or set chat.
Since these APIs have a semantic meaning that generally strings
lag, they should be preferred to state descriptions
when they apply.
OK.
Let's briefly now talk about forms and form fields.
When conveying that a form field, say an edit text,
is in an error state, use text view's
set error method so each accessibility service
can handle the error in the most appropriate way.
In general, avoid using color alone to denote an error state.
In this example, the error state is only
communicated with a colored line, which could
be missed by a colorblind user.
But in this example, the text field error state
is communicated through multiple cues, title color, text field,
stroke, and an error message below the field.
You are no longer relying on color alone to convey state.
To summarize, for most built-ins,
avoid adding a control's state in the text label
since this information is likely already provided
by the accessibility service.
Use a state description to convey
the custom state of elements when
the state is likely to change.
Use a content description for static content.
And never rely on color alone to show that a form
element is in an error state.
Thank you for watching.