Search topics
Image uploads that never ask for alt text
A marketplace's listing form uploads each photo and publishes it with its file name as the alt text, without ever asking the seller what the photo shows.
img.alt = file.name; The problem
Shoppers who use a screen reader hear a file name instead of what a product looks like, because the form that published the photo never asked the seller to describe it.
Makers Market is a marketplace where small makers list what they sell. A seller lists a white enamel mug with a navy rim. The listing form has a title and an Add a photo button; the seller picks the photo from their phone, sees it appear in the listing, and publishes.
The form never asked what the photo shows. It wrote the file name, IMG_2041.jpg, as the image's alt text, because an image needs some alt text and that was the only text it had. A shopper using a screen reader reaches the photo and hears "IMG_2041.jpg, image". The seller described the mug carefully for the eye, in the photo, and nothing of that reaches the shopper.
The listing form is an authoring tool: something sellers use to make web content. EN 301 549 11.8.2 asks that an authoring tool "enable and guide the production of content" that meets the web requirements, and Section 508 504.3 asks for a mode that prompts authors to make content that conforms to WCAG. A form that never asks for a description does neither: it gives the seller no place to describe the photo, and it doesn't guide them to.
Filling in the file name makes it worse. The published photo now fails WCAG 1.1.1, since "IMG_2041.jpg" doesn't serve the purpose of the photo, but it has an alt attribute, so it looks finished to a check for the attribute and to the seller. Section 508 504.2 also asks that authors can override what is required for accessibility. Here, that means a seller must be able to mark a photo as decorative, so the override is the author's choice and not the tool's guess.
The failure reaches shoppers, not the seller who used the form, and every listing the form publishes repeats it. On a marketplace with thousands of sellers, one missing question in the form becomes thousands of photos that say nothing, which no single seller can fix.
3 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 (affected)
- Seizures (not affected)
- Without vision A shopper using a screen reader reaches the mug's photo and hears "IMG_2041.jpg, image", so they can't tell its colour, size or what it is made of, which is what the photo was there to show.
- Limited vision Someone who can make out only the shape of the photo, and turns to the screen reader for the detail, hears the same file name.
- Limited language, cognitive and learning abilities Someone who has listings read aloud to help with reading hears a string of letters and numbers in the middle of the description, with nothing it means.
axe checks that each image has an alt attribute, and this one has, so it passes. ANDI flags alt text that contains a file name, and this audit passes its alert on against the published image, as an image problem; it has no way to see that the form which made the image is the cause. Where a page the audit is given has a form that uploads images and has no field to describe them, it sends a review lead, since the form may ask on a later step it can't see. Most authoring tools sit behind a sign-in, so check the seller's own pages by hand.
AI image descriptions can fill the gap, and can mislead. A generated description of the photo ("a white cup on a table") says what is in the picture but not what a buyer needs: that it is enamel, holds 350 ml, and has a navy rim. Used as a suggestion the seller reads and corrects, it helps; published without being read, it is another default text.
Try it
List the enamel mug with its photo, then hear the published photo as a screen reader would.
- Press Add a photo. The demo picks IMG_2041.jpg for you, as a phone’s photo picker would.
- Do what the form asks, if it asks anything, and press Publish listing.
- The panel under the form says what a screen reader reads for the published photo.
Broken Can you fix this?
Screen reader says:
(Publish the listing, then move to its photo)
The fix
Ask the author what each image shows, before it is published, wherever the image comes from, and let them mark one as decorative.
- 1Ask for a description for every image, wherever it comes from, before it is published.
- 2Never fill in the alt text for the author with a file name, a title or the word image.
- 3Let the author mark an image as decorative, and publish it with an empty alt.
<form action="/listings" method="post"> <label for="title">Title</label> <input id="title" name="title"> <label for="photo">Add a photo</label> <input id="photo" type="file" accept="image/*"> <div id="photos"></div> <button type="submit">Publish listing</button></form>Ask for a description when the photo is added
<form action="/listings" method="post"> <label for="title">Title</label> <input id="title" name="title"> <label for="photo">Add a photo</label> <input id="photo" type="file" accept="image/*"> <div id="photos"></div> <button type="submit">Publish listing</button></form> <dialog id="describe" aria-labelledby="describe-title"> <form method="dialog"> <h2 id="describe-title">Describe this photo</h2> <img id="preview" alt=""> <label for="photo-alt">What does the photo show?</label> <p id="photo-alt-hint">Shoppers who can't see the photo hear this instead. Say what a buyer would want to know: colour, size, what it's made of.</p> <textarea id="photo-alt" aria-describedby="photo-alt-hint"></textarea> <p id="photo-alt-error" hidden>Describe the photo, or tick the box below.</p> <label><input type="checkbox" id="decorative"> It only decorates the listing: nothing to describe</label> <button value="add">Add photo</button> <button value="cancel">Cancel</button> </form></dialog>The form adds the photo the moment it is chosen and fills its alt text with the file name, so the seller is never asked what it shows and the published listing reads "IMG_2041.jpg".
The seller is asked what the photo shows at the moment they know it best, with a hint that says who the words are for and what to put in them. Adding the photo with neither a description nor the box ticked says what to do, beside the field, rather than adding it with no alt text. The box is the seller's override: a photo marked as decorative is published with an empty alt, so screen readers skip it.
Both pass. Asking when the photo is added gets the description while the seller is looking at the photo, and suits a form where photos only come in through the one button. Checking before publishing catches photos however they arrive, and lets a seller add several photos quickly and describe them together, but it asks later, when they are thinking about publishing. A tool with more than one way to add photos does best with both: the dialog for the button, the check for everything else.
Leave the alt attribute off until the author has answered. A missing alt is something a check can find; a file name, the listing title or the word "photo" looks finished and hides the gap. Publish an empty alt only when the author chose it. Save the description with the photo on the server, as a field of its own, so every page that shows the photo uses it.
Words in the field matter as much as the field. A label that asks "What does the photo show?" and a hint that says who it is for get better descriptions than a field called "Alt text", which many sellers won't know. Don't cap it at a few characters; a sentence is usually right, and anything longer, such as a size chart, belongs in the listing's text, as missing alt text on images that carry information explains.
An AI description can go into the field as a draft, marked as suggested, for the seller to read and change before adding the photo. Never publish one the seller hasn't seen, and never use it to skip the question.
Every way into the tool needs the same question.
- A photo dropped onto the page or pasted in arrives without the change event the dialog listens for, so drop and paste need the dialog, or the check, too.
- A bulk import from a spreadsheet or another shop needs a column for descriptions, and flags the rows without one.
- A photo added from the phone app needs the same field in the app.
- A seller needs to be able to edit a description later, from the photo in the listing, not only when it is first added.
The description step is part of the tool, so it has to work for authors with disabilities too. A seller who is blind may add photos a friend took; the dialog needs its name and focus moved into it and back, as modals that leave keyboard focus behind them explains, and an error tied to the field only while it shows.
Fixing this with an AI coding assistant? Get this guide as Markdown, or get every guide in your coding agent.
Verify the fix
4 checks, no mouse.
Test with: Keyboard, Screen reader
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after any change to how photos are added.
Limits
This guide covers how an authoring tool asks for image descriptions. The same clauses ask more of a tool than this. A text editor must let authors make real headings and lists rather than large bold text, as headings chosen by size, not by structure shows from the page's side, and keep them when text is pasted in or converted (EN 301 549 11.8.3, Section 508 504.2.1). Where the tool checks content, it must suggest a repair (11.8.4), and where it offers templates, at least one must be accessible and said to be (11.8.5). Whether the tool's own screens work for authors with disabilities is a separate question, which WCAG and ATAG 2.0 Part A cover. Test with your sellers, and with the shoppers who will read their listings.
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.
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.