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 (for elements that don’t support the alt attribute).
  • Via visually-hidden text (also for elements that don’t support the alt attribute).

 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

The screen reader voice is the voice synthesizer being used at any given time.

The language can be:

  • The language of your operating system.
  • The language of your screen reader UI.
  • The language of the web content.

In theory, as long as the language of all content was declared properly in the code, a screen reader should have no problem choosing the correct voice. However, in multilanguage situations (for example, when the screen reader UI is in Finnish and the web content in English), many screen readers have trouble switching voices (“accents”) as needed, so the user can end up listening to English text in a Finnish voice, or vice versa. b . In theory, as long as the language of the content was properly declared in the code, and the screen reader has the correct settings, English text should be read witn this context, the screen reader might read parts of the English text using a Finnish voice (or “accent”).

Our former colleague Xurxe Toivo García performed screen reader multilanguage experiments to study this buggy language behavior and come up with better practices.

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 implement, but it will usually be read in the right voice (almost 100% of the time in Xurxe’s experiments).