Search topics
AI alt text that misses or misreads what a photo shows
A shop's media library writes an AI description into each photo's alt text on upload and nobody reads it, so a planner in four colours is said to come in three.
photo.alt = await describeImage(photo.url); The problem
Screen reader users hear what an AI guessed from each product photo, so they miss what the photo is there to show, or are told something that isn't true.
A stationery shop sells a weekly planner for 2027 in four colours. Its product page has three photos: the sage cover, the planner open at a week, and the four colours side by side. The shop's media library has an AI alt text add-on. When a photo is uploaded, it sends the photo to an image description service and writes what comes back into the photo's alt text. Nobody opens the field, and the page goes live.
A screen reader user moves through the photos and hears "A green notebook on a white table, image", then "An open notebook with lines on the pages, image", then "Three notebooks in green, blue and pink, image". None of them is a file name or the word "image", and each sounds careful. The first two name what is in the photo and leave out why it is there: that this is the 2027 planner, and that it shows a week across two pages, with a box for notes. The third is wrong. There are four planners, and their colours are sage, navy, terracotta and sand. A shopper who would like the terracotta one hears that it comes in pink, and never hears of sand.
Success criterion 1.1.1 Non-text Content asks that an image that carries information has a text alternative that serves the same purpose. These photos are there to sell the planner: to show its cover, its layout and its colours. The description service gets the pixels and nothing else. It doesn't know the product, the page, or that the third photo is where shoppers choose a colour, so it names the objects it recognises, and where it misreads the photo, the text alternative says something the photo doesn't. A sentence that leaves out what the image is there to show, or gets it wrong, doesn't serve the same purpose, however fluent it is.
The service did what it was asked to do. The failure is in how its answer is used: it goes straight into the alt attribute, which the page publishes, with no step where a person who knows the product reads it. Microsoft's guidance for its own automatic alt text in Office is to review and edit what it generates, and to remove notes it adds such as "Description generated with high confidence". An add-on that writes into the alt field on upload leaves that review out.
Alt text is also what shows when a photo fails to load, and what reading and translation tools get. In a shop, it is often the only way to learn what a product looks like before paying for it.
2 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (not affected)
- Reach, strength (not affected)
- Cognitive (not affected)
- Seizures (not affected)
- Without vision A shopper who uses a screen reader hears "Three notebooks in green, blue and pink" and has no way to know the photo shows four planners, none of them pink. They choose a colour the shop doesn't sell, or never hear of the one they would have chosen.
- Limited vision Someone who can make out the shapes in a photo but not its colours or the small gold year on the cover turns to the alt text for those details, and gets a guess.
axe looks for an image with no alt attribute, and ANDI for alt text that contains a file name. These alts pass both: they are full sentences. No checker can compare a sentence with a photo and know which colours the shop sells. This audit sends a review lead for alt text that still carries a generator's own note, such as "Description generated with high confidence", since the note is meant to be deleted when a person reviews the text. Generated text without such a note looks like any other alt text. A second AI asked to check the first, given only the photo, sees the same pixels and knows no more about the product.
Try it
Upload the planner’s photos and see what goes into their alt text.
The panel under the editor shows what the AI wrote into each photo’s alt text. Can you read or change it in the editor? Then apply the fix: correct each description against its photo before you tick its box.
Broken Can you fix this?
Weekly planner 2027, A5
Photos
In each photo’s alt text, which a screen reader reads on the product page:
(Upload the photos)
The fix
Have a person check each AI description before it goes live.
// When a photo is uploaded to the media librarymedia.on('upload', async (photo) => { photo.alt = await describeImage(photo.url); await photo.save();}); // When the editor's Publish button is pressedapp.post('/products/:id/publish', async (req, res) => { const product = await products.get(req.params.id); await product.publish(); res.redirect(product.url);});What is wrong4 points
- The upload handler writes the service's answer straight into the alt text, so it is published the moment the product is.
- The editor shows the photos but never their descriptions, so nobody reads them before Publish.
- The cover and inside photos are described by what is in them, without the year, the layout or the notes box.
- The colours photo is described wrongly: three notebooks instead of four, and pink instead of terracotta.
// When a photo is uploaded to the media librarymedia.on('upload', async (photo) => { // A draft for a person to check. The photo has no alt text until they have. photo.altDraft = await describeImage(photo.url); photo.alt = null; await photo.save();}); // When the editor's Publish button is pressedapp.post('/products/:id/publish', async (req, res) => { const product = await products.get(req.params.id); for (const photo of product.photos) { if (!req.body[`checked-${photo.id}`]) return res.sendStatus(422); photo.alt = req.body[`alt-${photo.id}`].trim(); await photo.save(); } await product.publish(); res.redirect(product.url);});How it is fixed5 steps
- Save the service's answer as a draft in a field of its own, and set no alt text yet. Nothing the AI wrote can reach the page by itself.
- Show each draft in the editor, in a text box beside its photo, labelled with the question the description has to answer.
- Tie a short hint to the box saying the text is an AI draft to check against the photo.
- Add a required box to tick for each photo. The browser won't send the form until every photo has been checked, and the server refuses to publish without them too.
- On Publish, write what the person checked or rewrote into the alt text. An empty box they ticked becomes
alt="", for a photo that adds nothing.
This fixes the Before and passes 1.1.1, as long as the person checking can see the photos and knows the product. The draft still saves typing; what makes it a text alternative is that someone who knows why the photo is on the page has read it.
Every way generated text arrives. The draft field has to cover each route by which a description service reaches the alt text, not only the upload button.
- A bulk run over the media library, which many alt text plugins offer for images with no alt. In WordPress, a decorative image's alt field is left blank, just like a forgotten one, so a bulk run describes the dividers and backgrounds too.
- A review screen with an Accept all button. It is a review in name only: one click publishes every draft unread.
- An import from a product feed, a spreadsheet or another shop, where the descriptions were generated somewhere else.
- A button that regenerates the description of one photo. It must write over the draft, never over alt text a person has checked.
Context makes a better draft, not a checked one. Some services take the product's name or the page's keywords along with the photo, and their drafts get closer. They still can't see which colours the shop sells or what a shopper is choosing between, and they still misread a photo now and then, so the draft is still a draft.
One photo, several places. A media library usually keeps one alt per image, but the same photo can be the product's colour chart on one page and a decorative banner on another. Let the description be set where the photo is placed, or overridden there: as the W3C's images tutorial explains, the right text depends on why the image is on that page.
Decorative is a choice. An empty alt is right for a photo that adds nothing the text doesn't say, and only a person can decide that. A generated description on a divider is noise, and an empty alt on the colours photo would hide the colours. See decorative images read out as file names or repeated text.
Words and data in the picture. A photo of a size chart or a label needs its words in the alt text or, better, as text on the page. A service that reads text in images can misread numbers, just as it can colours. See images of text instead of real HTML text.
Verify the fix
4 checks, no mouse.
Test with: Screen reader
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after changing the description service, its settings or how photos are added.
How screen readers handle aria-describedby
Limits
This is a starting pattern, not a guarantee for every application. describeImage, media and products stand in for your own services. This guide covers generated descriptions published unread. An image with no alt, or a file name in it, is covered in missing alt text on images that carry information, and an upload that never asks for a description at all in image uploads that never ask for alt text. Charts and graphs need more than one sentence of alt text and have a topic of their own. Browsers that describe images with no alt text themselves, such as Microsoft Edge, are the reader's own tool, not the page's text alternative, and don't make an image without alt text pass. Test with the people who will buy from the page.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
References
- WCAG Understanding: non-text-content (opens in a new tab)
- WAI Tutorial: images/decision-tree (opens in a new tab)
- WAI Tutorial: images/informative (opens in a new tab)
- support.microsoft.com: everything-you-need-to-know-to-write-effective-alt-text-df98f884-ca3d-456c-807b-1a1fa82f5dc2 (opens in a new tab)
- developer.mozilla.org: img (opens in a new tab)
EaseWeb service
Fixed it? Keep it from coming back.
I turn guides like this one into rules your coding agents follow and checks your CI runs. Then I retest by hand with a keyboard and screen readers, periodically.