Images and WCAG — what the standard actually requires

Most people meet WCAG through a compliance panic: a legal letter, a procurement questionnaire, or an auditor’s report with four hundred red rows, most of them about images.

This guide is about what the standard actually asks for — and about the gap between passing an automated check and being usable by an actual human, which is wider than the tooling suggests.

The rule, in one line

The relevant criterion is WCAG 1.1.1 Non-text Content (Level A). Level A is the floor — not the aspiration, the floor. It says, in effect:

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.

The two load-bearing words are equivalent purpose. Not “a description”. Not “some text”. Text that does the same job the image was doing.

That distinction is the whole subject, and it is the one automated tools cannot check.

What an automated checker actually verifies

Run any accessibility scanner and it will check, essentially, one thing about images: is there an alt attribute?

It cannot check whether the alt text is correct. alt="image" passes. alt="IMG_4032.jpg" passes. alt="running shoes cheap trainers buy online" passes. All three are useless to the person the rule exists for, and all three turn a red row green.

So a clean automated report means one thing: you have no missing attributes. It does not mean your site is accessible, and anyone selling you the first as the second is selling you a number.

The four categories that decide what you write

WCAG does not want a description of every image. It wants the equivalent purpose, and that depends on the job the image is doing. In practice every image falls into one of four buckets.

Informative images carry content the surrounding text does not. A photo of a damaged component in a repair guide; a headshot next to a quote. → Describe what matters about it, briefly.

Decorative images carry nothing. Background textures, dividers, the stock photo of a laptop that exists to break up the page. → alt="". An empty attribute, deliberately. This tells assistive technology to skip it entirely. Omitting the attribute is not the same thing — some screen readers then read the filename aloud, character by character, which is an actively worse experience than silence.

Functional images do something. An image inside a link; an icon that is a button. → Describe the action or the destination, not the picture. A magnifying glass icon that opens search is alt="Search", not alt="magnifying glass".

Complex images — charts, graphs, diagrams, infographics — carry more information than a sentence can hold. → A short alt text identifying it, plus the actual content somewhere a sighted user can also read it: a data table, a caption, a paragraph. If your chart’s meaning exists only in the picture, everybody loses, including the people who can see it.

Most alt text failures are really classification failures. People write a description for a decorative image and skip the functional one.

Text inside images

If your image contains words — a quote card, a poster, a promotional banner, a screenshot of an error message — those words are content, and a person who cannot see the image cannot read them.

They belong in the alt text. And if the image is anything more than a handful of words, the honest answer is that it should not have been an image in the first place. (WCAG has a separate criterion about this, 1.4.5, which essentially says: use real text unless you have a good reason not to.)

Screenshots in documentation are the classic offender. The error message in the screenshot is the single most important string on the page, and it is invisible to search, to translation, to copy-paste, and to anyone using a screen reader.

Fixing a site that shipped without alt text

The realistic playbook, in the order that actually works:

1. Fix the templates, not the images. Crawl the site and group the missing alt text by template. Almost always, a handful of templates — the product card, the article header, the category banner — generate the majority of the failures. One template fix closes thousands of rows. Do this before touching a single image.

2. Mark the decorative ones as decorative. A large fraction of “missing alt text” is not missing at all: it is images that should have alt="" and were never told so. This is fast, and it shrinks the real problem substantially.

3. Draft the rest, then edit. What is left is genuine content images, and there are more of them than anyone has time for. Generate a description for every one of them with an AI pass, then review — hard on the images that carry meaning (charts, screenshots, product shots), quick on the rest.

That third step is the one that used to make projects stall, because “write four thousand descriptions” is not a task anyone schedules. PicsTag will produce a draft for all of them in the browser — feed it a CSV of your image URLs, export a CSV of descriptions, and join it back onto your CMS.

Be clear about what that gets you: a model can produce the draft, it cannot produce the judgement. It does not know why the image is on the page, so it cannot tell an informative image from a decorative one, and it will cheerfully describe a background gradient. The classification above stays human. That is the actual work, and it is much smaller than the writing was.

Passing versus being usable

Here is the test that matters more than any scanner: turn on a screen reader and use your own page.

VoiceOver ships with every Mac and iPhone; NVDA is free on Windows. Spend twenty minutes navigating your own product page or article with the screen off. You will learn more in that session than from any report, and you will hear, immediately, which of your alt text is useful and which is noise.

Compliance is a floor you are legally obliged to reach. Usability is the thing you were presumably trying to achieve. They are not the same, and only one of them is checked by a robot.