In this chapter, you’ll continue making improvements to Taco Tuesday. By the end of the chapter, you’ll have applied what you learned to give the app helpful descriptions, labeling and layouts that are more perceivable for people using screen readers and other assistive technologies.
In Chapter 2, “Hello, Accessibility!”, you learned how to add content descriptions and in Chapter 3, “Testing & Tools”, you learned about screen readers. You should read both chapters before starting this one.
To learn these topics, you’ll continue working on the Taco Tuesday app. Either open the project you’ve been using in the previous chapters or find and open the starter project in the materials for this chapter.
Perceivable is the first category that the WCAG defines for how to make your app accessible. Here’s the definition provided in the WCAG documentation:
1. Perceivable: Information and user interface components must be presentable to users in ways they can perceive.
This means that no matter if someone is consuming your app visually or through audio or touch, they can identify what’s on the screen.
Throughout this book, you’ll see these quotes from the WCAG documentation to guide you on your way and give you a reference if there’s a topic you’d like to look deeper into. When it applies, you’ll also see the level they rated the guideline so you know if you’re reaching Level A, AA or AAA conformity by applying it.
To focus on perceiving the app in a way you might not normally, this chapter will have a heavy focus on screen readers.
Understanding screen readers
While you’ll mostly use TalkBack in this book, there are many screen readers out there. For example, BrailleBack gives feedback through a braille readout.
Including effective text alternatives
In Chapter 2, “Hello, Accessibility!”, you learned how to add a content description to a view, which informs a screen reader about the contents of that view. Content descriptions are especially important for views without text, such as images and icons. They help your app adhere to the first guideline:
Hiding decorative content
In Chapter 2, “Hello, Accessibility!”, you also used
android:contentDescription="@null" to signal to the accessibility services that it can skip that view. This meets one of the detail items under Success Criterion 1.1.1:
Setting the content description to null
This is the option you’ve used before in this book:
Setting the ImportantForAccessibility XML attribute
Android supports the
importantForAccessibility attribute for API 16 and higher. If a device is running at least Android 4.1, the accessibility services will not highlight or read a view with this attribute.
Writing clear descriptions
You now know a lot about why and where you should use content descriptions. It’s also helpful to know how to write a good content description. The best way to write a description changes depending on what you’re describing.
Icons are often used as an actionable button or to show state. When an icon is used as a button, you often use a verb for the description. If you have a pencil icon button to edit a contact, Edit contact is much more meaningful than Pencil. You want to describe what the icon does.
In most cases, you don’t need to add content descriptions to text. The text should speak for itself. Exceptions include situations where you have a compound drawable that the user should understand along with the text, or if you have symbols in the text that the user should perceive differently.
Perhaps one of the hardest types of items to describe are images. There can be a lot of content in a single image. How much should you share?
Creating adaptable layouts
How you lay out your app changes the experience for your users. You want your layouts to be adaptable for however people are perceiving them. There’s an entire section of the WCAG about making your app adaptable.
Using headers is an effective way of organizing your content. It allows a person to identify and skip directly to the section that interests them. It associates the content in that section with a common topic.
Grouping related items
Another way you can make the screen easier to navigate is by grouping items. It’s tedious to walk through every single item to get to the content you want. By grouping related items together, you can remove unnecessary steps.
Allowing all screen orientations
It may come as a surprise that supporting both portrait and landscape in your app makes it more accessible.
<dimen name="discover_card_width">424dp</dimen> <dimen name="discover_card_height">230dp</dimen>
Inputs are a place for potential confusion. When working with them, it’s important to make it clear what the input does.
Using a view to describe input
There’s another way to accomplish this: using
TextInputLayout. Start by deleting the
TextView that serves as a label for this input. Then, surround the input with this view:
<com.google.android.material.textfield.TextInputLayout android:id="@+id/recipe_detail_notes_input_layout" style="@style/ Widget.MaterialComponents.TextInputLayout.OutlinedBox" android:layout_width="match_parent" android:layout_height="match_parent" android:hint="@string/recipe_detail_hint_notes"> <com.google.android.material.textfield.TextInputEditText ... /> </com.google.android.material.textfield.TextInputLayout>
recipeDetailNotesEditText.visibility = View.VISIBLE recipeDetailNotesLabel.visibility = View.VISIBLE
recipeDetailNotesInputLayout.visibility = View.VISIBLE
recipeDetailNotesEditText.visibility = View.GONE recipeDetailNotesLabel.visibility = View.GONE
recipeDetailNotesInputLayout.visibility = View.GONE
Supporting text scaling
As a quick detour from the Text Alternatives and Adaptable categories above, here you have a sneak peek of Distinguishable.
- The first thing to consider when making your app accessible is whether it’s perceivable.
- You should provide content descriptions for any non-textual elements.
- Notating headers makes your app easier to navigate.
- By grouping related items, users can consume related information together.
- To make your app accessible, you should support all screen orientations.
- Labeling inputs makes it clear what they’re for.
- By using scalable pixels and avoiding static height text views, you allow for scaling text.
Where to go from here?
You now have some foundational knowledge about what it means to make your app perceivable. Great work! Continue thinking about how you can apply these things to your own apps and what might be stopping your content from being perceivable.