Who writes the alt text for a picture nobody drew?

Alt text has always had an author, and it has always been someone who knew what the picture showed: the photographer, the illustrator, the person who chose it from a library and looked at it while choosing.

That chain is so reliable we never wrote it down. Generated images break it, and the replacement almost everyone reaches for first is the one that does not work.

Why not just use the prompt?

Because the prompt describes a request, and alt text describes a result. Those are the same sentence often enough to be dangerous and different often enough to matter.

The illustrations on this site are generated, and one of the early ones was briefed as a white cane leaning against a doorframe. What came back was a doorframe with no cane in it. Prompt-derived alt text would have announced a white cane to every screen reader user who reached that image, on a post about disabled students, with nothing in the page to contradict it.

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

WCAG 1.1.1 asks for a text alternative serving an equivalent purpose. A description of an image that does not exist fails that in the worst available way, not by omission, which a listener can detect, but by confident fiction, which they cannot.

What does the image itself have to say?

The alternative is to describe the picture that actually exists: send the finished image to a vision model and ask what it shows.

That is what I do on this site now. Each drawing goes to claude-opus-5 with an instruction to reply in one sentence, under twenty words, naming only what is visibly depicted. No "an image of", no mood, no interpretation, no mention of style or medium. If the shapes do not resolve into a recognizable object, 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", which is what it looks like, rather than what it was asked to be. Two drawings were described as resolving into no recognizable object, because they do not. A model declining to invent a subject is exactly the behavior I want.

Is that good enough?

Not on its own, and I want to be careful here because this is the point where a tools post usually starts overclaiming.

What I measured: every image on this site has a description derived from the image. Median sixteen words. The whole pass cost about sixteen cents. Those are facts.

What I have not established: whether these descriptions are good. A vision model describing a generated image is one machine characterising another's output, and it can be fluent and wrong. It has no idea why the picture is on the page, which is information alt text often needs.

And one description came back truncated. The model's own reasoning consumed the token budget and the sentence stopped mid-clause, "...the shapes do", which would have been read aloud as a complete thought. That is now caught and discarded rather than stored, but it is a reminder 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 would recommend is generated descriptions with human review, and saying so rather than implying the pipeline solved it.

What would a good practice look like?

• Describe the result, never the request. Whatever generated the asset, the description comes from the asset.
• Constrain the description. One sentence, visible content only, no interpretation. Long alt text is its own accessibility problem.
• Let it say "I cannot tell." A description that admits the image is abstract is more useful than one that invents a subject.
• Reject truncation. If a description stops early, store nothing. A half sentence is announced as a whole one.
• Review them as a set. A contact sheet of thirty-one images and their descriptions takes twenty minutes and catches what per-image review does not.
• Keep the brief as a record of the request, not as a description. It is useful history. It is not what the picture shows.
• Re-describe when the image changes. A new drawing needs a new description. A caption describing a picture that has been replaced is the original problem with extra steps.

The wider thing this is an instance of

More of what we ship will begin as generated output: copy, images, components, layouts. Every one of them arrives with a gap between the request and the result, and that gap is invisible to whoever can perceive the output directly.

Our accessibility practices were built around a human who looked at the thing and described it. We are removing that human from a great many workflows while keeping every assumption that depended on them.

Look at the last generated asset you shipped. Ask what its text alternative was derived from. If the answer is the prompt, let's fix that one today. It is cheap now, and it is a confident lie told to the people least able to detect it.