(upbeat music)
- Hello. I’m Shailen Tuli.
I’m an engineer in Android Developer Relations working on accessibility.
And today my colleague, Yinglei and I will be talking to you
about two topics of interest to developers. I will first discuss accessibility checks
that have just become available in Android Studio.
Then Yinglei will talk about the state of accessibility in Jetpack Compose.
The new checks in Android Studio are backed by the Accessibility Test Framework
for Android, or ATF. So let’s talk about ATF a little bit first.
ATF is an open source project.
ATF examines your views and the accessibility noted for objects
that are sent by the framework to accessibility services,
and it offers suggestions for improving your app’s accessibility.
Common accessibility services include TalkBack,
a screen reader used by blind and visually impaired users,
and Switch Access,
which lets users interact with Android devices
using one or more switches.
ATF has been available for many years
and developers have used ATF through various endpoints.
For example, Accessibility Scanner Tool, available for free from the Play Store,
runs ATF’s checks under the hood.
You can think of accessibility scanner as a front end for ATF.
ATF checks can also be bundled
with existing Espresso and Robolectric test suites.
And when that is done, ATF checks run along with existing tests
and they flag accessibility issues in the UI.
These same ATF checks are now available in Android Studio.
These are available in Canary builds at the time of this recording
but should be landing in a stable Studio release.
So these checks run automatically as you build your layouts,
and if accessibility issues are found, suggestions show up in Studio’s issue panel,
and when you apply the recommended fix, the suggestions clear.
And if you’ve minimized the issue panel, you can still know about the flag issues
by looking at the icon on the issue panel toggle button.
So let’s make things concrete by opening up Android Studio
and writing some code
and seeing how ATF suggestions can help you make your layouts more accessible.
We’ll focus on three common accessibility problems found in many apps:
missing labels, inadequate touch targets, and poor contrast
between foreground and background.
Let’s start with a simple demo of a missing label.
Consider this image button which does not have the content description.
This image button cannot be properly discovered by screen reader users
and they will hear unlabeled button, or something equally unhelpful,
when they focus on it.
This generates an ATF warning in Studio’s issue panel.
Notice that Studio links out to support documentation,
which provides greater detail about this and other issues related to content labeling,
a nd which also shows you the recommended fixes.
You can make the image button more accessible
by adding the content description in the form of a localized string.
And when you do that, the ATF warning in the issue panel disappears.
Now let’s demo how Studio surfaces ATF’s checks
related to inadequate touch targets.
Consider this example of a 24dp x 24dp image button,
which is not considered large enough for reliable interaction.
This elicits of warning in the issue panel along with the recommendation
that you should make the image button at least 48dp wide and 48dp high.
Why is this important?
For users with limited touch, physical strength, or mobility,
small touch targets may be difficult to interact with.
Even users with perfect touch, may struggle to easily use such controls
if their touch position is temporarily impaired.
For example, when they’re walking or riding a bus.
Let’s apply the suggested fix,
setting a min width of 48dp and a min height of 48dp.
This makes the ATF warning in the issue panel go away.
Of course, this is only one way to increase the touch area for view.
You could also set the layout width and the layout height to 48dp or larger,
or if you didn't want to make the icon larger
you could add some padding.
You could also use the touch delegate API
to redefine the hit track and expand out the touchable area
of a view beyond that view’s actual maps.
And now let’s demo how Studio surfaces ATF’s checks
related to poor color contrast.
So why is contrast so important?
Many users with less than perfect vision
struggle with content that is not sufficiently contrasted.
And even users with great vision
have trouble looking at screens with poor contrast
in bright outdoor settings.
Consider this text view
with a gray text color over a light gray background color.
The contrast between the two gray colors falls short of recommended contrast ratios.
Studio surfaces a warning in the issue panel
and notes that this view’s text contrast ratio is only 3.56:1,
and it recommends you increase to the best practice minimum ratio
of 4.5:1 or higher.
You can make the text a bit darker, or you can make the background a bit lighter,
or you can do both, and that should fix the contrast ratio problem.
Okay, so let’s make the background a bit lighter
and doing this takes us beyond the recommended 4.5:1 contrast ratio,
and the warning in the issue panel now goes away.
You should strive for a 4.5:1 or higher ratio between foreground and background.
For large text defined as 18 point or higher, for regular text of 14 point or greater,
for bold text, a 3:1 contrast ratio might be adequate.
Note that maintaining a good contrast ratio applies to images as well as to text.
Also note, the contrast between pure white and pure black is 21:1.
So you can have lots of room for creativity even while providing enough contrast.
So we've looked at three ways
in which the Accessibility Test Framework checks in Studio
can help you make your apps more accessible.
ATF looks for many things beyond missing labels, inadequate touch targets,
and poor contrast, but in the interest of time,
we focused on those three checks here.
These ATF checks can help you improve your app’s accessibility
while you’re still developing the app,
and you should strive to eliminate all of Studio’s warnings.
If you find that ATF and Studio have flagged something that is working well,
you can opt to ignore the check.
And finally, while these checks are invaluable,
they are no substitute for manually testing your app
with accessibility services.
Automated checks have their limits.
For example, Android Studio and the Accessibility Test Framework
can tell you if you’re missing a label,
but they cannot evaluate if the label is actually helpful,
and they cannot guarantee the UI’s accessibility.
You should manually test your apps
by turning on services like TalkBack and Switch Access
and you should have actual users of assistive technologies try out your app.
Please try out these checks in Studio.
If you have suggestions for improvement, please follow back in the issue tracker
using the information provided in the top description below.
And now I’ll hand it over to my colleague Yinglei,
to tell you about the state of accessibility in Jetpack Compose.
Over to you, Yinglei. - Thanks, Shailen.
Hi, I'm Yinglei.
I’m a software engineer working on Android accessibility.
I will talk about the current state of accessibility in Jetpack Compose.
We have made a lot of progress in the past year
and we're excited to share it.
Jetpack Compose is Android’s modern toolkit for building native UI.
It simplifies and accelerates UI development to Android.
I will first give a very brief introduction of Jetpack Compose.
Jetpack Compose is built around composable functions.
These functions let you define your app’s UI programmatically
by describing its shape and data dependencies
rather than focusing on the process or the UI’s construction.
Here is an example of a simple composable function.
It has two text elements vertically aligned in a column.
The UI will look like this picture.
Additionally, we’ve added a clickable modifier to make this UI clickable.
In Compose, we use modifiers to change the behavior composables.
Most of built-in composables like text or button
have accessibility support out of the box.
In this example, when we enable TalkBack on a fourth person column,
it will say, “Jetpack Compose, Simple Demo. Double tap to activate”.
However, sometimes the framework needs more information
to understand how to describe a UI element to the user.
We call this information semantics. Jetpack Compose will convert the semantics
to accessibility note in full optics in Android.
I will talk about some of the most common use cases
which require developer effort.
The first use case I want to talk about is content description.
In Jetpack Compose,
content description is a mandatory parameter for icon image
because it is very important for accessibility.
Here we have an icon button. The content description is currently null.
When TalkBack focuses on the button, it will say button.
What does this button do?
A TalkBack user has no idea.
Now, let’s set the content description to a localized string, remove item.
This time, when TalkBack focuses in the button,
it will say, “Remove item, Button”.
It is much better, right?
If an image icon is purely decorative,
we should set the content description to null.
In our example, the gingerbread image
should use a null content description
because the adjacent text already exposes images semantics.
This will prevent TalkBack from announcing the image at all.
When TalkBack focuses on the card item, it will say,
“Gingerbread, A tag line, $4.99, Qty, 2”.
The second use case is access with the action labels.
Action labels are used to inform the user
about actions that will happen when they interact with a UI element.
If you are familiar with the view-based APIs,
this is the same label parameter
in real compact replace accessibility action method.
Here for the SnackItem, we apply a clickable modifier
and a supplier on click callback
which will be performed when the item is clicked.
By default, TalkBack will describe the clickable with a hint,
double tap to activate.
You can customize the action label if you want.
Here we set the unclick label to a localized string, “show_details”.
Now, when TalkBack speaks the hint of this item
it will say, “Double tap to show details”.
The third use case is merging.
Accessibility services like TalkBack and Switch Access
allow users to move focus across element on the screen.
It is important that elements are focused at the right granularity.
If every single low level composable in your screen
is focused independently,
a user will have to interact a lot to move across the screen.
Here we have a row of two text elements.
Total one is the price.
By default, they are not merged.
TalkBack will focus separately on these two text elements.
To merge the two text elements,
we add a semantics modifier on the row
and we specify mergeDescendants = true.
Now TalkBack will focus on the two texts elements as one block.
Note that some UI elements like button
and modifiers like focusable and clickable will do this for you.
We’ve now shown some common accessibility use cases.
As you saw for these common use cases, Compose provides dedicated parameters
like content description and unclick label for less common use cases
where there is no dedicated parameter.
You can use the semantics modifier to directly set specific semantics properties.
In this example, we mark certain texts as headings for accessibility
so users can quickly navigate between them.
As I mentioned earlier,
most built-in composables already have accessibility support
and need very little extra developer effort.
If you want to build your own custom UI components,
you need to manually supply the semantics information.
I recommend you read the code of the equivalent built-in Compose widget
and specify the same semantics,
and when possible, avoid the low level semantics modifier
in favor of high level modifiers,
because a lot of them already have accessibility support built in.
To learn more about Jetpack Compose and accessibility
check out the Android developer links.
We also have a public user tracker to report bugs or request new features.
This information is provided in the talk description below.
That was an overview of the new accessibility features for Android developers,
accessibility checks in Android Studio, and Jetpack Compose accessibility.
Please try them out.
Suggestions and feedback through the posted links are very welcome.
Thank you.