Who writes the alt text for a picture nobody drew?

The drawings on this site are generated. One of the early ones was briefed as a white cane leaning against a doorframe, and what came back was a doorframe with no cane in it.

That small miss broke something I hadn't noticed I was leaning on. Alt text has always had an author, and that author has always known what the picture showed. It was the photographer, the illustrator or the person who picked it from a library and looked at it while picking.

That chain is so reliable we never wrote it down. Generated images break it, and the fix almost everyone reaches for first doesn't work.

The prompt is not the picture

The prompt describes a request, and alt text describes a result. Often they're the same sentence, which is exactly what makes the habit dangerous, because they're different often enough to matter.

Take the doorframe. Alt text taken from the prompt would have announced a white cane to every screen reader user who reached that image. The post was about disabled students, and nothing on the page would have contradicted it.

Sighted readers would never have caught it. They see a doorway, and their eyes smooth over the gap without noticing. So the error is only visible to the people who can't check it.

WCAG 1.1.1 Non-text Content asks for a text alternative that serves an equivalent purpose. A description of an image that doesn't exist fails that about as badly as it can.

Think about what that means for a listener. They can tell when a description is missing. They can't tell when one is confident and made up.

The description comes from the picture that exists

The alternative is to describe the picture that actually exists, so that's what I do now.

Each finished drawing goes to a vision model, claude-opus-5. The instruction is to reply in one sentence, under twenty words, naming only what is visibly depicted.

It rules out "an image of", mood, interpretation and any mention of style or medium. And if the shapes don't resolve into a recognizable object, the model is told to say so plainly.

The results are more honest than the briefs were. The printing-blocks drawing came back as "An open box holding stacked bundles, with one bundle propped upright against the rim". That's what it looks like, even though it isn't what it was asked to be.

Two drawings were described as resolving into no recognizable object, because they don't. Fair enough: a model that declines to invent a subject is doing what I want.

That is not good enough on its own

Now, this is the point where a tools post usually starts to overclaim, so I'll go slowly.

Here's what I measured. Every image on this site has a description taken from the image itself. The median is sixteen words, and the whole pass cost about sixteen cents.

What I haven't established is whether these descriptions are good. I don't know. A vision model describing a generated image is one machine describing another machine's output, so it can be fluent and wrong. It also has no idea why the picture is on the page, and alt text often needs that.

And one description came back cut off. The model's own reasoning used up its token budget, and the sentence stopped mid-clause, at "...the shapes do". A screen reader would have read it as a complete thought.

A description like that is now caught and thrown away instead of stored. But it still reminds me that an automated description can fail in a way that sounds finished.

So I treat this as a better default, not a finished answer. What I'd recommend is generated descriptions with human review, and I'd say so openly, rather than imply the pipeline solved it.

Good practice describes the result, never the request

Most of it is in the story already. The description comes from the image, whatever made the image, and never from the request. The brief is still worth keeping, as a record of what was asked for, but it isn't what the picture shows.

Keep the description to one sentence about what's visible, with no interpretation, because long alt text is an accessibility problem of its own.

Let it say "I cannot tell". A description that admits the image is abstract is more useful than one that invents a subject.

If a description stops early, store nothing, because a half sentence gets announced as a whole one.

Then review them as a set. A contact sheet of thirty-one images and their descriptions takes twenty minutes, and it catches what reviewing one image at a time does not.

And describe the image again when it changes. A new drawing needs a new description. Otherwise the caption describes a picture that's gone, and we're back at the doorframe.

I don't think this stops at images. More of what we ship will start as generated output: copy, images, components, layouts. Each one arrives with a gap between the request and the result, and anyone who can see the output directly won't notice the gap.

Our accessibility practices were built around a person who looked at the thing and described it. We're taking that person out of a great many workflows, and we're keeping every assumption that depended on them.

A description taken from the prompt is cheap to fix now, and the people it misleads are the ones least able to catch it.

So look at the last generated image you shipped, and ask what its text alternative was taken from. If the answer is the prompt, let's fix that one today.