Text alternatives

 

What are they?

Image content can be photos, illustrations, drawings, icons, charts, diagrams, etc. Image content can have either one of two roles:

  • Informative: when it conveys information, and that information is not provided in the surrounding text.
  • Decorative: when it doesn’t convey information; or when it does, but the information is already provided in the surrounding text.

Informative image content must have a suitable text alternative, which can then be announced by screen readers. Text alternatives can be provided in multiple ways:

  • Via the alt attribute (for elements that support it, namely <img>, <area>, and <input type="image"> elements).
  • Via ARIA-based approaches, mainly aria-label and aria-labelledby.
  • Via visually-hidden text.

 General tips

  • Don’t include the words “image” or “image of”. The screen reader already announces that for <img> elements, and in other cases it’s understood from the context.
  • Don’t just describe the content of the image in a literal or generic way.
  • Ask yourself: what information am I trying to convey with this image content?
  • Imagine a blind person sitting next to you. How do you tell them the information conveyed by the image?

For example, in the context of an article about one of the wheelchair tennis winners at the Rio 2016 Paralympics, don’t simply write “woman on wheelchair” as a text alternative. Instead, you could provide something like “Dutch player Jiske Griffioen celebrates after winning the gold medal on the women’s singles event at the 2016 Summer Paralympic Games in Rio de Janeiro, Brazil” (or whatever else the image is conveying).

Context dependence

The proper way to compose a text alternative depends on the context. Let’s take the example of the Wunder logo, provided as an <img> element:

  • If it’s part of a grid full of logos of all the companies supporting a project, you should use alt="Wunder", and similarly for the other companies. Then the screen reader will come around and read: “Supported by Wunder, Apple, Google…”.
  • If you really need to communicate the fact that it’s a logo, you could use alt="Wunder logo".
  • If you really need to communicate what the logo looks like (for example, in the context of a design discussion), you could write something like alt="The Wunder logo: A very stylized carrot, in a vibrant shade of purple. It has three overlapping oval-shaped leaves, and its general roundness makes it resemble a beetroot or radish".

Let’s take another example. Sometimes we use card links, containing an <img> element and a title. When we click on that link, we’re taken to another page that prominently features the same image.

  • On the card, the image is decorative. We should use an empty text alternative (alt=""), so that it will be ignored by screen readers.
  • On the article page, the image may be decorative or informative. Hint: if you’re using some kind of stock photography, it’s probably decorative!

Architects, content designers, content creators, and developers all must work together to implement good text alternative practices.

Screen reader language bugs

Multilanguage situations, unfortunately, lead to buggy language behaviour in all the combinations of screen readers, operating systems, and browsers we’ve tested. An example of a multilanguage situation is when the screen reader UI is in Finnish and the web content in English; in this context, the screen reader might read parts of the English text using a Finnish voice (or “accent”).

Here are Wunder’s Xurxe Toivo García performed experiments regarding this; check out his Screen Reader Multilanguage Experiment and Accessible Labelling Multilanguage Experiment.

One of the most common bugs is that text content given as an HTML attribute (for example, text alternatives provided with alt or aria-label) is often announced in the wrong voice.  While there’s nothing we can do about <img> and the other elements where the alt attribute is required, we do have a choice about other elements:

  • We can provide the text alternative using ARIA-based approaches. This is easier to implement and maintain but often read in the wrong voice (over 50% of the time in Xurxe’s experiments).
  • Alternatively, we can provide the text alternative as visually-hidden text, nested inside the element in question. This is a bit harder to do, but it will usually be read in the right voice (almost 100% of the time in Xurxe’s experiments).

Resources