The arithmetic that breaks manual alt text
Alt text is trivial for one image and brutal for a catalogue, because the count scales on three axes at once: products, images per product, and variants. A modest apparel brand hits five figures fast.
| Catalogue | SKUs | Images each | Alt strings | Manual hours (40s each) |
|---|---|---|---|---|
| Small shop | 200 | 4 | 800 | 9 |
| Growing DTC brand | 1,200 | 5 | 6,000 | 67 |
| Established retailer | 4,000 | 5 | 20,000 | 222 |
| Multi-brand catalogue | 15,000 | 6 | 90,000 | 1,000 |
The variant axis is the one that surprises people. A shirt in six colours and five sizes is thirty variants, but it is usually six distinct images — one per colour. Alt text should follow the image, not the variant. Teams that generate one string per variant produce five identical rows for every colour, inflate their word count, and create exactly the repetitive pattern that search engines discount.
Most catalogue audits measure the percentage of images with a non-empty alt attribute. A templated catalogue scores 100% on that check while being functionally useless. Coverage is a floor, not a quality measure — you need a distinctness check alongside it.
Because the arithmetic never improves, the only durable answers are automation with human review, or a decision to invest human attention only where it changes an outcome. In practice you want both.
What alt text has to do for two very different readers
Every string you write serves two audiences with genuinely different needs, and at scale the tension between them is what makes rules hard to write.
The screen reader user
- Already heard the product title — repeating it wastes their time
- Needs what the image adds: angle, fit, texture, what is in shot
- Is hurt by keyword stuffing, read aloud word by word
- Wants brevity; long strings are fatiguing across a grid
The search crawler
- Uses alt text as one signal among filename, caption, and page context
- Rewards specific, distinct descriptions over repeated boilerplate
- Discounts obvious stuffing and duplicate strings
- Increasingly parses images directly, reducing alt text's solo weight
The good news is that these overlap more than they conflict. A description written honestly for a screen reader user — specific, concrete, non-repetitive — is also the version a crawler treats best. Writing for accessibility first and accepting the SEO benefit as a by-product is a more reliable rule than trying to optimise both, and it is far easier to encode into a repeatable process.
Three rules survive contact with scale:
- Describe what the image shows, not what the product is. The page already carries the product name. "Rear view showing padded laptop sleeve and mesh straps" beats "Black Canvas Backpack".
- Keep it under roughly 125 characters. Some older screen readers truncate near this point, and long strings read poorly aloud.
- Skip "image of" and "photo of". Screen readers already announce that it is an image; the prefix is pure noise repeated thousands of times.
One genuine exception: purely decorative images should carry an empty alt="", which tells assistive tech to skip them. That is a deliberate choice, not a gap — and it is why a raw coverage percentage is a misleading metric.
Three ways to produce alt text at volume
There are only three mechanisms, and mature catalogues use all three on different slices of inventory.
1. Structured templating. Assemble a string from fields you already hold: category, colour, material, shot type. "{colour} {material} {category}, {shot_type}" yields "Tan leather crossbody bag, front view". It is cheap, instant, and completely predictable. It is also blind — it describes your database, not the photograph, so it cannot mention that the strap is adjustable or that the model is holding it over one shoulder.
2. Vision-model generation. A model looks at the actual pixels and describes them. This is the only method that captures what is genuinely in the frame, which makes it the right tool for secondary and detail shots where the template has nothing to say. The cost is variance: models occasionally state a colour confidently and wrongly, and "navy" described as "black" is a real accessibility error that no spell check will catch.
3. Human writing. Accurate, contextual, and expensive. Reserve it for the pages where the return justifies it.
| Method | Speed | Describes the actual image | Risk | Best for |
|---|---|---|---|---|
| Templating | Instant | No | Repetitive, thin | Primary shots, large tails |
| Vision model | Minutes | Yes | Occasional factual error | Detail and lifestyle shots |
| Human | Hours | Yes | Cost, inconsistency | Top revenue pages |
The hybrid that works: template the primary image where your structured data is reliable, generate for secondary images where it is not, and hand-write the top 50–100 products by revenue. That last group is small enough to be affordable and important enough to be worth it.
When generating, pass the known colour, material, and category into the prompt as constraints rather than asking the model to infer them. You own that data in your PIM; a model guessing at "sage" versus "olive" under warm store lighting does not. Let the model describe composition and detail — the things only the pixels can tell you.
Where alt text actually gets lost
Most catalogues do not lack alt text because nobody wrote it. They lack it because it was written somewhere that does not survive the trip to the storefront.
Alt text lives on the image record in your platform, not in the image file. Photographers frequently write careful IPTC captions into the file metadata — and every one of those is discarded the moment the JPEG is uploaded, because the platform stores alt text in its own database column. Teams discover this after a full shoot's worth of descriptions vanishes.
The common leak points:
- Bulk CSV re-imports. A product import that omits the alt text column can blank existing values across the catalogue in one operation.
- Re-uploading a retouched image. Replacing an image often creates a new image record. The old record's alt text does not follow it — this is the single most common way a well-tended catalogue silently regresses.
- Theme templates that drop the field. A custom collection grid or a quick-view modal that hardcodes
alt=""undoes the work invisibly, since the data is intact and only the rendering is broken. - Third-party apps that write images without setting metadata.
The second point is worth designing around directly. If your retouching workflow ends with a manual download-and-reupload, you are re-entering metadata by hand on every refresh. Tools that push a finished image back into the product record — Retouchable sets filename, alt text, and gallery position on the push — remove that regression at the source rather than asking a person to remember. Our walkthrough of how Shopify handles image metadata fields covers what each field controls on the storefront.
Reviewing generated text without reviewing all of it
Nobody proofreads 20,000 strings. But you do not need to — you need enough evidence to trust the batch, and a rule for what gets escalated.
Run automated checks on 100% of output, then human-sample what passes. The checks are cheap and catch the failures that matter:
Flag automatically for review: strings over the character limit; strings beginning "image of" or "photo of"; any string appearing more than twice across the catalogue; strings that merely repeat the product title verbatim; and — the important one — any string whose stated colour disagrees with the colour field on the variant. That last check is a simple string comparison against data you already hold, and it catches the highest-severity class of generated error before it reaches a shopper.
Then pull a 2% random sample for a human to actually read. On a 20,000-string batch that is 400 items, about three hours, and it is enough to tell whether the batch has a systemic problem. Read them aloud, or better, run a page through a screen reader — a string that looks fine in a spreadsheet cell often reveals itself as unbearable when spoken in sequence with forty others.
A flat random sample over-represents your long tail. Stratify: sample your top-revenue products more heavily than your discontinued stock, because that is where an error is actually seen. The same three hours buys far more protection.
If the sample shows a consistent failure — every boot described as "shoe", say — fix the prompt or template and regenerate that segment. Do not patch strings individually; a systemic error deserves a systemic fix, and regeneration costs you minutes where hand-editing costs days.
A rollout order that front-loads the value
Do not start at SKU 1 and work alphabetically. Traffic and revenue in a catalogue are steeply concentrated, so the sequence you choose determines how much of the benefit you capture in week one versus month three.
A workable four-stage order:
- Top 100 products by revenue, hand-written. Small, affordable, and it establishes the voice that everything else imitates. Keep these as the reference examples for your prompts and templates.
- Everything with existing organic search traffic. Pull the list from your analytics. These pages already rank; improving their image signals compounds on traffic you have rather than traffic you hope for.
- Current season and active lines. Generated, sampled, shipped.
- The long tail. Templated. Genuinely fine — a predictable, accurate template on a product nobody visits is a better use of the budget than a bespoke sentence.
Then make it part of intake rather than a project you repeat. Alt text should be a required field at the point a product is created, not a quarterly clean-up. A brand shipping 40 new SKUs a month accumulates 2,400 missing strings a year if the step is optional — which is how catalogues that were audited clean in January are broken again by autumn. Our catalogue audit checklist covers the wider set of image fields worth checking on the same cadence.
Proving it worked
Alt text improvements are slow and diffuse, which makes them easy to abandon before they pay. Instrument them or you will never know.
Track four things, and be honest about the timescale on each:
| Metric | Source | When to expect movement |
|---|---|---|
| Distinct alt strings / total images | Your own catalogue export | Immediately |
| Google Images impressions | Search Console, Images tab | 4–12 weeks |
| Accessibility violations | axe, Lighthouse, or WAVE | Next crawl |
| Assisted conversions from image search | Analytics, segmented | One to two quarters |
The first metric is the one to watch weekly, because it is the only one entirely within your control and it is the one that distinguishes real work from templated filler. Coverage tells you a field is populated; distinctness tells you it was populated with something worth reading. A catalogue at 100% coverage and 30% distinctness has a problem that no coverage report will ever surface.
Run the accessibility scan on templates rather than pages — one product page, one collection grid, one quick-view modal. Violations there are structural and reproduce across thousands of URLs, so fixing a template is worth more than fixing any number of individual records.
And set a re-audit date. Catalogues regress, mostly through image replacement and bulk imports, so the realistic goal is not a permanently clean catalogue but a short and predictable interval between drift and detection. Quarterly is enough for most brands; monthly if you are shipping products weekly.