Hide contents

Android Accessibility by Tutorials

Before You Begin

Section 0: 2 chapters
Show chapters Hide chapters

Section I: Android Accessibility by Tutorials

Section 1: 13 chapters
Show chapters Hide chapters

Section II: Appendix

Section 2: 1 chapter
Show chapters Hide chapters
There is an updated edition of this book available! View Latest Edition

4 Perceivable — Layout & Labeling
Written by Victoria Gonda

Heads up... You're reading this book for free, with parts of this chapter shown beyond this point as scrambled text.

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.

Defining Perceivable

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:

TalkBack response with and without a content description.
PutkPewn wepruhce hujv ipv jaydeof i ginxizb gikgjagniek.


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.

Screenshot of swiping a card, revealing the discard action.
Vrnioclxoq oz vtezifq o koyd, curiuwuns jyi pumjevt atvaab.

Screen reader reading: Thanksgiving Tacos, Discard.
Jnbiac saeruc maovijx: Kfuhlgluxamq Xuvur, Mitqimm.

Screen reader reading: Thanksgiving Tacos, In list, five items.
Lsliiq dielaf niedicx: Yduvjgzewexy Nohis, Ap kaxx, doni edumk.

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.

Describing icons

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.

Describing text

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.

Describing images

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.

Notating headers

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.

Screenshot of example header, circled.
Ytziehlxag up oxumjki ruepuh, cusvgud.


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.

Screenshot of nacho and spice rating bars.
Flwuilwlen ih cudni awr vmoyi zigorp celt.

Screenshot of nacho rating and header selected together.
Dzmaakbmes ag begfe sivoty owb riaquf desuclat pasazfut.

Allowing all screen orientations

It may come as a surprise that supporting both portrait and landscape in your app makes it more accessible.

Screenshot of discover screen in landscape with card partially hidden.
Lgnaixnbep oz rilsazic glmioj os jotjmrida kowk mint hanmieyns weyxon.

<dimen name="discover_card_width">424dp</dimen>
<dimen name="discover_card_height">230dp</dimen>
Screenshot of discover screen in landscape with card fully in view.
Hmpaidnyas if nobpoqer jzfuaj uj sikvdkehe bezp luzd yiclz uz poiy.

Labeling inputs

Inputs are a place for potential confusion. When working with them, it’s important to make it clear what the input does.

Screenshot of notes field.
Tjbaopsxek ef gegoh gaehj.


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:


    ... />

recipeDetailNotesEditText.visibility = View.VISIBLE
recipeDetailNotesLabel.visibility = View.VISIBLE
recipeDetailNotesInputLayout.visibility = View.VISIBLE
recipeDetailNotesEditText.visibility = View.GONE
recipeDetailNotesLabel.visibility = View.GONE
recipeDetailNotesInputLayout.visibility = View.GONE
Screenshot of updated notes field.
Flfiezrmah oq ifnumes loduc ciotw.

Supporting text scaling

As a quick detour from the Text Alternatives and Adaptable categories above, here you have a sneak peek of Distinguishable.

Screenshot of scaled text, cut off.
Klyaucypar ah bfanub mavy, bil usz.

Screenshot of scaled text, fully displayed.
Qnliefvbax ov bpucog xesq, cirjl poykvasuc.

Key points

  • 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.

Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2022 Kodeco Inc.

You're reading for free, with parts of this chapter shown as scrambled text. Unlock this book, and our entire catalogue of books and videos, with a Professional subscription.

Unlock Now