Providing text alternatives for non-text content

Reading Time: 6 minutes

I recently ran a session with some of our content developers covering alternative text, and the difference between alt text and captions. It seemed to be well received, so I thought I’d write it up.

“Text alternatives” is the first guideline of the first principle of WCAG 2.1. It’s literally the first thing to think about – and the reason why is pretty simple: not everyone can see images.

That may be because they have a vision disability. But it could also be because the image has been deleted, renamed or moved. Maybe their network connection is poor. Or their browser doesn’t support the format. Or they have disabled images in their email client because they have a 500MB monthly limit.

Whatever. It happens. Text alternatives are what users rely on when images are not available. Like this one right here:

The alternate text needs to replace the image. So your question becomes very definite:

What text do I need to provide if this image is not available? How might I describe the appearance, purpose, function, or meaning of this image to someone who can’t access it?

The official W3C guidance

I started preparing for the session by re-reading How to meet WCAG, the Worldwide Web Consortium (W3C for short) guidance for web content creators.

The first thing that struck me was how intimidating it looked. The guidance is split over 6 different scenarios, with up to 20 different techniques for each. It includes techniques for ARIA attributes and other technologies that most content authors won’t know anything about.

It looks very scary and technical, and there is a lot to take in.

So it’s no wonder people get confused by it all, and it reassured me that it’s worth my time to deliver the session.

The second thing that struck me was the precise wording of guideline 1.1.1 Non-Text Content:

Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

How to meet WCAG (Quick Reference)

It’s the phrase “Provide text alternatives for any non-text content” that’s of interest. It implies two things:

• This is not just about pictures: it also covers graphs, video, and audio. Basically, anything that’s not text
• It’s not about ‘alt text’, it’s about text alternatives – and note the plural

And if you do read the guidance, it is pretty clear that alt text (or alt attributes, more precisely), is just one part of the picture for providing text alternatives.

Under the hood

The most basic way to include an image on a web page is with HTML something like this:

<img src="/picture.png" width="800" height="600" alt="A description of the picture">

This basically tells the browser: place an image here, this is where you will find it, its dimensions, and some alternate text. The alt attribute is generally what most people think of when we talk about text alternatives. But as guideline 1.1.1 makes clear, it’s not the only way, and we shouldn’t limit ourselves to considering it alone.

Something a bit more user-friendly

So, having decided the W3C guidance was a bit ferocious for my audience, I looked around for something a bit more approachable.

The first thing I remembered was an article called What is the Difference Between Alternative Text, Long Description, and Caption? by Deborah Edwards-Oñoro, published as part of the HTMHell advent calendar.

It’s brief and gets straight to the point, and breaks text alternatives into three categories:

• Alternate text
• Long descriptions
• Captions

Edwards-Oñoro describes the distinction between them as:

• Alternate text replaces the image
• Long descriptions can be used for more complex images; they are bits of text next to the image that describe or discuss, or otherwise complement, the non-text content
• Captions provide supporting information, available to all

I liked the straightforward approach here, but felt it lacks nuance. Writing text alternatives can be tricky, and it’s not always easy to know what the alternative should be.

The Australian Government style guide

I found this quite by chance, but I rate it highly. It’s clear, comprehensive, and practical.

I won’t regurgitate it here, but in summary:

• Use empty alt attributes alt=”” for decorative images
• For informative or complex images, use context, captions and alt attributes together to give all users access to the same information
• For functional images, like search icons, or logos that link to the home page of a website, describe the function of the link in the alt attribute

Read the Australian Government Style guide on Alt text, captions and titles for images

Key concepts

• Orient people. Place non-text content within document structure (headings, basically) so they know what it’s about
• Use the environment. Alt attributes are not your only means of describing visual content for non-visual users
• Use captions judiciously, but also use just plain old body copy to do the job
• It’s fine to say “as figure 1 shows, Scotland’s employment rate is the highest it’s been in 20 years” in body copy, as long as “figure 1” is programatically identifiable
• Use a combination of in-copy, alt text and caption to describe the full meaning of the image or non-text content. This is OK – the people who rely on this information have had years to figure this out, and they’re much better at it than you or I
• Don’t fret too much. Do your best. If you do anything at all, most visually impaired web users will be enormously grateful because their experience of the web is overwhelmingly crap

Concluding thoughts

The W3C, perhaps realising that their official guidance is not the easiest document to get your head round, have published an image tutorial that can help you decide how to go about providing text alternatives.

Based on this, I wrote a little app to help you understand how best to include text alternatives for image-based content.

Some feedback from an actual screen reader user

After drafting this post, I got involved in a conversation on Mastodon with Léonie Watson (see below) and Amelia Bellamy-Royds – both contributors to the W3C web accessibility initiative – amongst others.

Léonie uses and relies on a screenreader to use the web. So her experience trumps mine any day of the week. Here’s what she said:

I think that image descriptions are important, but that detailed info about the product shouldn’t be limited just to images/text descriptions.

The WAI info on providing descriptions is a bit out of date and I’d suggest a different approach – using a disclosure. For example:

https://front-end.social/@tink/109936580698340073

```
<details>
<summary><img src="img.png" alt="Short text description"></summary>
//Long/detailed description
</details>
```

This way the detailed description is available to anyone who wants it but doesn’t take up screen estate by default. You can also structure the content inside the disclosure to use headings, lists, tables, as well as more prose.

https://front-end.social/@tink/109936585269524140

For me, as a screen reader user, the headings are the most useful feature. They let me navigate efficiently between the available products. The list markup is useful to the extent it lets me know how many items are displayed, though in this case because Ocado uses an infinite scroll it’s less useful because only the number of listitems in the DOM are announced, not the total.

https://front-end.social/@tink/109936986562139131

So there you have it: describe really meaningful images in body content, using standard conventions (headings, tables, lists) as much as you can. If you do this, alt attributes for images can, and should, be very brief.

If necessary, you can put longer descriptions in some kind of disclosure/details/accordion component immediately before or after the image. Just make sure it’s discoverable by assistive tech, and operable with just a keyboard.

As always, it depends …

What is the context? Who are the users? What do they need?

An image of a woman in a blue summer dress will need a very different text alternative in a news article compared to what’s required on a fashion e-commerce site.

This is why we can’t automate our way out of this; the web is for everyone. It needs humanity to make it work.

The bottom line is … you’re a content creator. Help all your content consumers understand what it is about as best you can. There is no right or wrong choice.

Accessibility overlays are not on option; human empathy is essential.

… and a footnote: on emotion in images

In an exchange that lasted 10 years, Léonie Watson – who is blind, relies on a screenreader, is a web developer, and contributor to W3C – and Jake Archibald, a former Google developer advocate, had this fascinating exchange.

• Thoughts on skin tone and text descriptions – Tink – Léonie Watson
• Writing great alt text: Emotion matters – JakeArchibald.com
• Text descriptions and emotion rich images – Tink – Léonie Watson

[This post was edited on 18 May 2023 to reflect the fact that Jake Archibald has left Google.]

One final thought

In everything you publish, make one thought uppermost in your mind: do not strive to meet technical standards. Instead, try to understand, and address, the needs of people.

If you do that, the next time you see those standards will be in your rear-view mirror as you whizz way beyond them.

Update: on screenshots of code

28 August 2023

Quite by chance, I came across this very good blog post by Ben Myers on How I write alt text for code snippets on social media.