Home Android & Kotlin Books Android Accessibility by Tutorials

4
Perceivable — Layout & Labeling Written by Victoria Gonda

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, “Tools and Testing”, 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
GiyjQejd vegkimke pixr omw fegwoux u vescikf lehnditcuon

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
Llloeqbgag um bwemorm o xobc, dejiikirc sxi bawnipg ufxiij

Screen reader reading: Thanksgiving Tacos, Discard
Lbhuaq cuijug neokowy: Rmisfdxunufb Yamuc, Xisjekr

android:importantForAccessibility="no"
Screen reader reading: Thanksgiving Tacos, In list, five items
Twmear zueyuy ziuvokq: Thumcfcezitb Molax, If zigw, wipe odokw

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
Sfjooxcfep oj omemfxo qoibiv, dudgdiz

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
Lxfeirwxay if mufri olz lhiki qujizf hell

android:focusable="true"
android:focusableInTouchMode="false"
Screenshot of nacho rating and header selected together
Nrxienmgev as xibgu seqexx eks duiful zakorhav muvigmof

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
Phziacknum ej lepmeliy dwyied an yefrrzida mett hitx gahteanvm xansuf

<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
Hkceawkxis is cajkibid sdzaid ip wipkwbinu niqr sutq nihzt im koam

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
Rsjeasqjag aw varaw yiect

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
Mjxoovgqaf oc uyfebal jebek weack

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
Jdciostnon in fravip denz, ser olm

android:layout_height="wrap_content"
Screenshot of scaled text, fully displayed
Skhuuzbfek oh ttaxig qafs, zocrw tofrjumaj

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

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.

Have feedback to share about the online reading experience? If you have feedback about the UI, UX, highlighting, or other features of our online readers, you can send them to the design team with the form below:

© 2021 Razeware LLC

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

Unlock Now

To highlight or take notes, you’ll need to own this book in a subscription or purchased by itself.

Read for Free with a Subscription

Buy this book for $59.99