How to Make Android ImageViews Accessible with Content Descriptions

Share on FacebookShare on LinkedInShare on Twitter

Developer using Android phone and creating content descriptions

When using Android Accessibility APIs, there are multiple ways to provide alternate text for an object, and the content description attribute is the most basic.

Imagine trying to go through a step-by-step guide with pictures you can't see. The content description attribute links a text description to a control, ImageView, or other focusable object that otherwise has no text content. These objects wouldn't be accessible without some some sort of label or description. ImageViews nearly always require a content description to be made accessible for TalkBack users.

So to get you familiarized with just how to make Android ImageViews accessible with content descriptions,  I'm going to cover the following in detail:

  • Why ImageViews are inaccessible without content descriptions
  • How to implement accessible content descriptions
  • When NOT to use content descriptions for ImageViews
  • Best practices for ImageViews and content descriptions

This post  references our open source app.  You'll want to get this running on your device and turn TalkBack on. You can also find our app on the Google Play Store.* The open source app is the preferred reference. Before continuing, find the "Content Descriptions" story, located in the main menu, and navigate to the "broken" tab. The following discussion will refer to the "broken" tab page as well as the "fixed" tab page.

*Please note: the version currently available on the GooglePlay store may be an older version than the one referenced in the open source repository.

ImageViews without Content Descriptions

You might ask, "why do images specifically require content descriptions, but not labelFor attributes?". The answer:  images are generally one of two types: 1) those that provide additional information (active, informative, etc) like in a step-by-step guide and 2) those that are simply accents next to other UI elements like bullet points or icons.

The latter could be considered "labeled by" their corresponding visual labels, but what's going to happen if we make that association? Is any additional information shared with the user?Unfortunately not; there's just an additional focus target to skip through when using TalkBack gestures. It's better to ensure that the listView element encapsulates both the visual label and the image, so that they're one focusable element.  This creates the visual association for partially sighted users, and keeps non-sighted users from dealing with redundant information.

Clearly adding a labelFor property to the  first type of images is not going to add any information. But it makes sense to add a content description that explains the image to a non-sighted user.

Take a look at the various types of accessibility issues* that can crop up when you have images with  missing content descriptions. Now I'll explain  how to fix them.

*Download our app to view.

What to Do: Missing Content Description

If a content description is completely omitted from an ImageView's attributes, they image cannot be focused on using TalkBack. This is clearly inaccessible since TalkBack users won't even know that the image in question exists. Without content descriptions, TalkBack users lose valuable information that ImageViews provide. An example of TalkBack's behavior can be found in the cat image in the broken tab of our app. This image wasn't assigned a content description, so TalkBack users are unable to focus on it.

What to Do: Empty Content Description

If a blank content description*  is given to an ImageView, TalkBack produces results that are inaccessible.

Sometimes TalkBack announces something like, "Image 54, Unlabeled." This behavior can be seen by highlighting the dog image in the broken tab of our app. The behavior of an empty content description is not consistent or accessible for TalkBack users.

* an empty or null string, either hard coded in XML or in a separate string file.

Duplicate Information

Even if an ImageView has a content description that isn't blank, it does not guarantee that the ImageView is entirely accessible. Content descriptions need to be concise and unique. So it's not a good idea to simply replicate a visible label of the ImageView. As seen with the fish image in the broken tab of our app, a content description that exactly matches visible text is not helpful to TalkBack users. In the fixed tab, you can see that a content description that adds information is more useful. For instance, if you have a visible label that says "Fish" next to an image that is of a fish, the content description should not also be "Fish." It's important to describe the information otherwise conveyed by sight in the content description, so instead of simply "Fish," you can say something like: "Red fish drawing on yellow background." For more complex images, you should be sure to focus on just the most important parts of the image so the content description doesn't become too wordy.

Implementing Accessible Content Descriptions

Fortunately, implementing content descriptions is simple. You can do this by adding the contentDescription attribute to your XML layout.

[code language="xml"] <ImageView android:layout_width="wrap_content" android:layout_height="wrap_content" android:src="@drawable/fish" android:contentDescription="@string/fish_content_description"/>
[/code]

It can also be done programmatically by calling the setContentDescription method in your Java file.

[code language="java"] View view = inflater.inflate(R.layout.fragment, container, false);
imageView = view.findViewById(R.id.image_view);
imageView.setContentDescription(getResources().getString(R.string.content_description));
[/code]

Either method provides TalkBack with all the necessary information to describe the ImageView to users.

When NOT to Use Content Descriptions

ImageViews don't always require a content description. Decorative images, certain logos, and ImageViews inside of ListViews or TabLayouts shouldn't have a content description. In these situations, it's actually worse to include a content description,  because adds unnecessary information and slows down navigation for TalkBack users.

Content Descriptions: Best Practice

Content descriptions make ImageViews accessible when used appropriately and correctly. Concise, unique content descriptions should be used for images that describe visual information to sighted users. They shouldn't be used for decorative or background images. You also shouldn't be using content descriptions when an icon is enclosed in a parent view that contains descriptive information such as in a ListView or TabLayout cell. The Android Studio lint checker may give a warning for any ImageView that's missing a content description, so you it's up to you to  determine if it's necessary to create one.

Deque How To Tips:

  • Add content descriptions programmatically for dynamic views
  • Test all views using TalkBack to ensure that you have used content descriptions effectively
  • Avoid using the word "image" or "photo" in your content descriptions. Simply describe what the image depicts

I  hope you found this tutorial useful. Check out our Android application for more accessibility tutorials and demos!

Learn More from Deque

This post was co-authored by Chris McMeeking and Melinda Kothbauer

Chris McMeeking is a software engineer and architect at Deque Systems, leading development efforts on Deque's native mobile accessibility analysis products. His journey in accessibility began through a project at the University of Michigan, The ASK Scanning Keyboard.  This application won multiple awards including the $100,000 Intel Innovator's Award, runner up at the Mobile World Congress, and the Student of Da Vinci award from the Multiple Sclerosis foundation. Chris is the lead developer behind the Android Analyzer, and an active member of the task force developing these new accessibility mobile standards.

About 

Chris McMeeking is a software engineer and architect at Deque Systems, leading development efforts on Deque’s native mobile accessibility analysis products. His journey in accessibility began through a project at the University of Michigan, The ASK Scanning Keyboard. This application won multiple awards including the $100,000 Intel Innovator’s Award, runner up at the Mobile World Congress, and the Student of Da Vinci award from the Multiple Sclerosis foundation. Chris is the lead developer behind the Android Analyzer, and an active member of the task force developing these new accessibility mobile standards.