Who writes the alt text for a picture nobody drew?

One of the early drawings on this site was briefed as a white cane leaning against a doorframe. What came back was a doorframe with no cane in it. (The illustrations here are generated, which I should probably have said first.)

That small miss breaks 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 chose it from a library and looked at it while choosing.

That chain is so reliable that we never wrote it down. Generated images break it, and the replacement 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 the two are the same sentence, which is what makes the habit dangerous. 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 in the page would have contradicted it.

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

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

A listener can detect a description that is missing, but they can't detect one that 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, with an instruction to reply in one sentence, under twenty words, naming only what is visibly depicted.

The instruction rules out "an image of", mood, interpretation, and any mention of style or medium. 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, and 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

The description isn't enough on its own, and this is the point where a tools post usually starts overclaiming, so I'll go slowly.

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

What I haven't established is whether these descriptions are good, and I don't know. A vision model describing a generated image is one machine characterizing another's output, and it can be fluent and wrong.

It also has no idea why the picture is on the page, and alt text often needs that information.

And one description came back truncated. The model's own reasoning used up the token budget and the sentence stopped mid-clause, at "...the shapes do". It would have been read aloud as a complete thought.

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

So I treat this as a better default and not as a finished answer. What I'd recommend is generated descriptions with human review. I'd also say so openly, and not imply that 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 asset, whatever generated the asset, 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.

I'd constrain the description to one sentence about visible content, with no interpretation, because long alt text is an accessibility problem of its own.

I'd let it say "I cannot tell", since 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 per-image review does not.

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

I don't think this stops at images. More of what we ship will begin as generated output, whether that is copy, images, components or layouts.

Each one arrives with a gap between the request and the result, and anyone who can perceive the output directly won't see that gap.

Our accessibility practices were built around a human who looked at the thing and described it. We're removing that human from 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 detect it.

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