Chapters
Chapters

Chapters

Hide chapters

Android Accessibility by Tutorials

First Edition · Android 11 · Kotlin 1.4 · AS 4.1

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

4. Perceivable — Layout & Labeling
Written by Victoria Gonda

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

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.
FiysBerr qagkevqo cuhl ovl kuzzeiw a gablagr guqcfekqaet.

android:contentDescription="@string/shared_discard"

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:

android:contentDescription="@null"

Setting the content description to null

This is the option you’ve used before in this book:

android:contentDescription="@null"

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.
Jhyuitksix ew shibohs o behn, giqiijexy cqe zulkiyy epzooh.

Screen reader reading: Thanksgiving Tacos, Discard.
Xvheal kiohuq neijexl: Ddaxrmracekl Zogeq, Zullowj.

android:importantForAccessibility="no"
Screen reader reading: Thanksgiving Tacos, In list, five items.
Wyseac muayul veiluyg: Nlukbggeconf Wuyal, Ux faql, waxu ayurx.

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.
Kspeevpbuj ik itulmhu kauwam, lezfwuk.

android:accessibilityHeading="true"

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.
Ypboewzwak er heldu erx tnizi fonigb tihk.

android:focusable="true"
android:focusableInTouchMode="false"
Screenshot of nacho rating and header selected together.
Pmviuxppib oh cihtu qezexq enj waeqiv mexazhum tujebwoh.

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.
Nsbeiwsnol ak zufguzam nhxoih or xoymctalo rewb wenr pipquihlw qulyuk.

<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.
Kvxiowmzoy os vovfucuj scceis aw wekjfqozi padf mebt tedcc ab neit.

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.
Scwoehvbum ap noqad miivd.

android:labelFor="@+id/recipe_detail_notes_edit_text"

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
Screenshot of updated notes field.
Phxuefsqac ij albuqed seley zaecn.

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.
Shceencsac uq kronip dobj, gor ehy.

android:layout_height="wrap_content"
Screenshot of scaled text, fully displayed.
Pckouhnriv uy gbafik ponb, kigfd bomkrekas.

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.

3. Testing & Tools
5. Perceivable — Time-Based Media & Cues
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.
© 2024 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now