Generating Image Alt Text With Vision Models in October 2026: Use Page Context, Skip Decorative Images, and Keep Humans Reviewing What Matters

Most sites have a backlog of images with missing or useless alt text: empty attributes on product photos, file names like IMG_4021.jpg read aloud by screen readers, or the same "image" placeholder on every chart. Vision-capable language models can now describe an image in a sentence or two, which makes it tempting to run every image through a model and paste the output into the alt attribute. That works better than doing nothing, but only if you treat the model as a drafting tool inside a pipeline with rules, context, and review. This guide walks through how to build that pipeline so the alt text actually helps people who rely on it.

What Good Alt Text Has to Do

Alt text is not a caption and not an image search keyword list. It is the text replacement for an image when the image cannot be seen. The Web Content Accessibility Guidelines (WCAG) success criterion 1.1.1, Non-text Content, asks that non-text content has a text alternative serving the equivalent purpose. The key word is purpose. The same photo needs different alt text depending on why it is on the page.

Take a photo of a red running shoe:

  • On a product page, the useful alt text describes the item: "Red mesh running shoe with white sole and reflective heel tab."
  • In a blog post about marathon training, it might be "A runner's worn red shoe after a long training run."
  • Used as a link to the shoe category, the alt text should describe the destination: "Shop running shoes."
  • As a background flourish next to a heading that already says "Running Shoes," it is decorative and should have an empty alt attribute (alt="") so screen readers skip it.

A vision model looking at the image alone cannot know which of these cases applies. That is the single most important design point: give the model the page context, not just the pixels.

Step 1: Classify Each Image Before Describing It

Before generating any description, sort images into types. You can do much of this with plain code, and use the model only where code cannot decide.

  1. Functional images. Images inside a link or button with no other text. Detect them from the DOM: an <img> that is the only content of an <a> or <button>. Alt text should describe the action or destination, so pass the link URL and surrounding labels to the model.
  2. Decorative images. Spacers, background textures, icons sitting next to text that already says the same thing. Many can be caught with rules: tiny dimensions, images referenced from CSS rather than <img>, or icons whose adjacent text matches their meaning. For the rest, ask the model to decide, and allow it to answer "decorative."
  3. Informative images. Photos and illustrations that add meaning. These get a short description.
  4. Complex images. Charts, diagrams, maps, and screenshots with lots of text. A one-line alt cannot carry all the data, so the alt text gives the takeaway and the full detail goes in nearby text, a data table, or a linked long description.
  5. Images of text. Banners or scanned notices where the text is the content. The alt text should contain that text, transcribed exactly.

Store the classification alongside the generated text. It makes review faster and lets you apply different rules per type later.

Braille signs mounted on a wall at a public library
Photo: Braille signs at Brisbane Square Library by John Robert McPherson, CC0, via Wikimedia Commons

Step 2: Build a Context Bundle for Each Image

For every image that needs a description, collect a small bundle of context from the page. Keep it short; you want signal, not the whole document.

  • Page title and the nearest preceding heading.
  • The paragraph immediately before and after the image, trimmed to a few hundred characters each.
  • Any existing caption (<figcaption>) and the current alt value, if one exists.
  • For functional images, the link target or button label.
  • For product images, structured fields such as product name, color, and material from your catalog.
  • The image type from Step 1.

The caption matters more than people expect. If a caption already says "Our team at the 2025 offsite in Denver," alt text that repeats it word for word makes screen reader users hear the same sentence twice. Tell the model to complement the caption rather than duplicate it.

Step 3: Write a Prompt With Clear Rules and a Structured Output

Ask for structured output so your code can validate it instead of parsing prose. A prompt along these lines works well:

You write alt text for images on a website.
Rules:
- Describe what matters for the purpose of the image on this page.
- Be concise: usually one sentence, rarely two.
- Do not start with "Image of" or "Picture of".
- Do not guess names, identities, ages, ethnicity, or emotions
  of people unless the page context states them.
- If the image contains meaningful text, include that text exactly.
- If the image adds nothing beyond nearby text, mark it decorative.
- If a caption exists, do not repeat it; add only what it leaves out.
- If you cannot tell what the image shows, say so in "confidence".

Return JSON:
{
  "decorative": boolean,
  "alt": string,
  "long_description_needed": boolean,
  "confidence": "high" | "medium" | "low",
  "notes": string
}

Page context:
{context_bundle}

A few of these rules deserve explanation:

  • No "Image of." Screen readers already announce that the element is an image, so the prefix wastes the listener's time.
  • No guessing about people. Models will happily infer a person's identity, age, or mood from a photo, and they can be wrong in ways that are embarrassing or harmful. Only name someone if the page text names them. Describe what is visible: "A woman speaking at a podium" rather than a guessed name or label.
  • Exact text. When an image contains a phone number, a price, or an event date, the model must transcribe it, not paraphrase it. Check this with OCR, covered below.

Step 4: Validate Every Output in Code

Never write model output straight into your HTML. Run cheap checks first:

  • Schema check. The JSON parses and has every required field.
  • Length check. Flag alt text that is very long for a non-complex image; long text usually means the model wrote a caption or an essay. Many teams aim for roughly one or two sentences.
  • Banned openers and filler. Reject or strip "image of," "picture of," "photo of," and phrases like "this image shows."
  • File name leakage. Reject alt text that contains file extensions or camera-style names such as DSC_ or .png.
  • Text accuracy. For images that contain text, run an OCR pass and compare numbers, dates, and URLs in the OCR output against the alt text. A mismatch goes to review.
  • Duplicate detection. If many different images on one page received identical alt text, something went wrong with context.

Escape the alt text properly when inserting it into HTML. A quotation mark in a model's output can break the attribute, and an unescaped string is an injection risk if any part of the context came from user-generated content.

An IBM Screen Reader keypad, a dedicated input device used to control early screen reading software
Photo: IBM Screen Reader Pad complete key pad by snuci, public domain, via Wikimedia Commons

Step 5: Route by Risk, Not Volume

Human review of every image does not scale for a catalog of tens of thousands of photos, and skipping review entirely is how wrong descriptions end up live. Route instead:

  • Auto-approve high-confidence outputs for low-stakes images that pass every validation check, such as generic stock photography in blog posts.
  • Queue for review anything with low or medium confidence, any image containing text, any functional image, anything showing identifiable people, and anything flagged as complex.
  • Always review images where a mistake has consequences: medical, legal, financial, and safety content, product images where the description affects a purchase, and instructional diagrams.

Make the review screen fast. Show the image, the page context, the generated alt text, and the classification side by side, with one-click approve, edit, or mark-decorative actions. Log every edit. Those edits are the best data you have for improving the prompt, and they tell you which image types the model handles poorly.

Step 6: Handle Charts and Complex Images Differently

For a chart, a good pattern is a short alt that states the type and the main finding, with the detail somewhere else on the page:

<figure>
  <img src="signups-2026.png"
       alt="Line chart: weekly signups roughly doubled from
            January to June 2026. Full data in the table below.">
  <figcaption>Weekly signups, January to June 2026</figcaption>
</figure>
<table> ... the actual numbers ... </table>

Vision models are not reliable at reading exact values off chart axes. If you have the underlying data, generate the summary and the table from the data, not from the rendered image. Use the model for charts only when the source data is genuinely unavailable, and route those to review.

Step 7: Make It Part of Publishing, Not a One-Time Cleanup

A backfill run fixes the past; the backlog comes back if new images keep arriving without alt text. Wire the pipeline into your publishing flow:

  1. When an author uploads an image, generate a suggested alt text immediately and show it in the editor as a pre-filled, editable field.
  2. Require an explicit choice before publishing: accept, edit, or mark decorative. Avoid silently filling the field, because authors stop reading suggestions they never had to confirm.
  3. Re-run generation when an image is reused on a different page, since the purpose, and therefore the right alt text, may change.
  4. Store the model version and prompt version with each generated alt text so you can find and regenerate entries after a prompt change.

Step 8: Test With a Screen Reader

Automated checkers can tell you an alt attribute exists; they cannot tell you whether it is useful. Periodically sample pages and listen to them with a screen reader such as NVDA on Windows, VoiceOver on macOS and iOS, or TalkBack on Android. Listen for repeated phrases, descriptions that miss the point of the image, overly long passages that interrupt the flow of the article, and decorative images that are still being announced. If you can, include people who use screen readers daily in this review; their feedback will be sharper than any checklist.

Common Mistakes to Avoid

  • Describing the image without the page. Context-free descriptions are technically accurate and practically useless.
  • Stuffing keywords for SEO. Alt text written for search engines instead of people reads badly aloud and does not serve the purpose of the image.
  • Treating every image as informative. Describing decorative images adds noise to every page visit.
  • Trusting text transcription blindly. A single wrong digit in a phone number or price is worse than a vague description.
  • Sending private images to an external API without checking policy. Internal documents, user uploads, and photos of customers may carry privacy obligations. Confirm what your provider retains and strip metadata such as location data before sending.

The Short Version

Vision models can draft alt text quickly, and for large backlogs they are a real improvement over empty attributes. The quality comes from everything around the model: classify images by purpose, pass page context and captions, forbid guesses about people, validate outputs in code, check transcribed text against OCR, send risky and uncertain cases to a human, and build the step into publishing so the backlog does not return. Then listen to the result with a screen reader, because that is the experience you are actually building.

Comments

Popular posts from this blog

Grok Bot - a step closer to AGI

Structured Outputs and Constrained Decoding for Reliable LLM APIs in Production (September 2026)

Tencent Hy4 Preview: Open 770B MoE Built for Real Work