WCAG Alt Text Requirements: The Complete Reference for Ecommerce Teams

Last updated: November 14, 2026

WCAG alt text requirements come down to one rule: Success Criterion 1.1.1 Non-text Content, a Level A requirement, which says every piece of non-text content needs a text alternative serving the same purpose. That sentence governs product photography, icon-only buttons, inline SVG, and canvas charts alike. What follows: what "equivalent purpose" means, a four-category decision framework, the formal pass/fail rules, and the edge cases most teams get wrong.

Key numbers: WCAG 2.2 defines 86 success criteria in force (4.1.1 Parsing is obsolete), with 55 at Levels A and AA — 1.1.1 Non-text Content is one of them, and it sits at Level A, the baseline (W3C). Missing alt text was detected on 53.1% of the top one million home pages in 2026, and 16.2% of all images analyzed had none — 10.8 per page (WebAIM Million, 2026). Another 10.8% of images that did carry alt text used a questionable or repetitive value such as a filename, putting more than one in four images in the missing-or-meaningless category combined (WebAIM Million, 2026). Automated tools catch roughly 60–70% of accessibility issues; alt text quality sits mostly in the manual 30% (TestParty internal data, as of 2026).

What does WCAG require for alt text?

WCAG requires a text alternative for all non-text content under Success Criterion 1.1.1 — a Level A requirement, the conformance floor every site is expected to clear — and that alternative must serve the same purpose the image serves for a sighted user, not describe its pixels (W3C, Understanding 1.1.1).

"Equivalent purpose" is the operative phrase, and it's why identical pixels can need different alt text depending on what the image is doing on the page — informational, functional, or decorative, each covered in the decision framework below. The image never changes; the correct text alternative does. (1.1.1 is one criterion inside the wider standard — see WCAG 2.2 AA explained.)

1.1.1 isn't scoped to `<img>`, and most compliance gaps live outside it:

• `<input type="image">` — `alt` is the button's only accessible name; omit it and a screen reader announces just "button."
• `<area>` in an image map — each hotspot needs its own `alt`; one alt on the parent `<img>` doesn't cover it.
• Inline `<svg>` — no native alt attribute exists, so an informative one needs `role="img"` plus a `<title>`, or an `aria-label`.
• Icon fonts — the glyph is invisible to assistive technology; the name has to come from an `aria-label`, never the glyph.
• CSS background images — no alt mechanism exists, so information conveyed only through one is inaccessible by construction.
• `<canvas>` — needs fallback content between its tags, or an `aria-label` pointing to an off-canvas data table.

Which type of image is this?

WCAG's four image categories — informative, functional, decorative, and complex — come from the W3C's own image decision tree: is it purely decorative, does it perform an action, is it too complex for one sentence? If none, it's informative.

Informative images convey content a sighted user gets by looking. Rule: describe the information, not the fact that it's a picture. Ecommerce example: a packshot's alt names the item and what distinguishes it — "Olive green linen midi dress with a self-tie waist" — not "image of a dress."

Functional images sit inside a link or button — an icon-only wishlist button, a thumbnail that opens a product page. Rule: describe the function, never the picture. Ecommerce example: a zoom icon gets `alt="Zoom in on product image"`, not `alt="magnifying glass icon"` — the shopper needs to know what pressing it does.

Decorative images add nothing informational — a divider graphic, a background flourish. Rule: `alt=""`, and empty beats missing. Empty is an explicit instruction telling assistive technology to skip the image; missing is ambiguous, and some screen readers fall back to announcing the file name or URL instead of silence. Ecommerce example: a gradient banner behind a "New Arrivals" headline that's already real text.

Complex images can't be summarized in one line — a size guide, a sales infographic, a data chart. Rule: a short alt naming the image, paired with the full content in adjacent text or a table it can reference. Ecommerce example: a size-chart JPG gets `alt="Size chart, described in the table below"` next to an actual HTML table, not a 200-word alt attribute trying to hold every row.

What are the formal pass/fail rules?

WCAG 1.1.1 fails on five recurring patterns: a missing `alt` attribute, a filename left over from the upload pipeline, a generic placeholder such as "image" or "photo," redundant phrasing like "image of," and a full description forced onto a genuinely decorative image. Each pattern either tells a screen reader nothing or buries the useful part in noise.

It passes on two patterns: `alt=""` on anything decorative, or alt text naming the correct equivalent purpose for anything informative, functional, or complex.

The gap between those two lists is where most real-world exposure lives: an automated checker can only test the first pattern — presence — never the second — quality. `alt="ss26dress04navy1200x.jpg"` satisfies any scanner looking for a non-empty attribute; it satisfies nothing else. In TestParty's audits of Shopify catalogs, alt text that exists but fails a shopper — a filename, a bare "image," a product title repeated across nine gallery photos — is consistently a larger finding category than alt text that's simply absent, a pattern reflected across the most common WCAG violations TestParty's dataset surfaces. That's the practical shape of the 60–70% automated-detection ceiling: tools clear the binary check; the quality judgment stays a human call.

How long should alt text be?

WCAG sets no character limit on alt text — length is guidance, not a success criterion. The widely cited ~125-character convention comes from older screen reader behavior, not from any WCAG requirement, and it's worth treating as a practical habit rather than a rule to defend in an audit.

What the convention gets right is emphasis: front-load the information that matters. A shopper listening to a page hears an image's alt before deciding whether to keep listening, so lead with the product and the distinguishing detail — color, material, fit — rather than working up to it through a scene-setting sentence.

What it doesn't license is keyword stuffing. Alt text written for a crawler instead of a listener — product-category keywords stacked into one attribute — fails 1.1.1 on the merits, since it no longer serves the equivalent purpose a sighted user gets, and it reads as manipulative to search engines' own spam classifiers besides. The same sentence that helps a shopper helps search: describe the photo once, plainly, and stop. Complex images are the exception to brevity — their full content has to live somewhere, just not crammed into the alt attribute.

What about product images specifically?

Product alt text adds one rule to the general framework: name the product plus whatever distinguishes this photo from the others in its gallery — color, angle, fabric detail, or context.

Product name + distinguishing attribute is the core pattern: "Olive linen midi dress, fabric close-up" beats a bare product title repeated on every image, since the title alone doesn't tell a shopper which photo they're on.

Variant images name the variant. A color or pattern swap needs to appear in the alt text itself — "in navy," "in heather gray" — rather than left for the shopper to infer from a swatch selection they may have already scrolled past.

Lifestyle and product shots earn different alt text, because they do different jobs. A packshot's alt describes the product in isolation — cut, color, material. A lifestyle shot's alt describes context — what it's paired with, who's wearing it, the setting — since that's what the image actually adds.

Galleries need per-image variation, not one string on nine photos. A workable pattern: the first image carries the fullest description (product, color, key attribute), and each subsequent image adds only what's new — "back view," "fabric close-up," "shown with matching bag" — rather than restating the full product name every time.

What do screen readers actually announce?

Screen readers announce alt text as part of an image's role, and the mechanics are consistent across tools even though wording varies: NVDA and VoiceOver both read the alt attribute's content, flagged as an image, then move on.

An empty `alt=""` is skipped entirely — the image is removed from the reading order, exactly as intended for decorative content. A missing `alt` attribute is handled inconsistently: some screen readers announce nothing, others fall back to the file name or full URL, which is why "missing" and "empty" aren't interchangeable outcomes.

`aria-label`, where present, overrides alt text completely — a screen reader announces only the `aria-label` string, never both — which is why a stale `aria-label` left over from an old redesign is worse than none at all: it wins over correct alt text sitting right next to it. For the component-by-component patterns this creates on a storefront — icon buttons, swatches, cart drawers — see ARIA labels for ecommerce.

The `title` attribute is not a substitute for either. Most screen readers don't announce `title` on images at all, and mouse-only users only see it after a hover delay most people never trigger. Treat it as tooltip decoration, never as an accessibility mechanism (MDN, `title` attribute).

How do you audit alt text at scale?

Auditing alt text at scale is a two-layer process: an automated checker finds every missing attribute in seconds, and a human reviews what's left, because quality judgment doesn't scale the way presence-checking does.

The automated layer belongs in continuous scanning, not a one-time pass — every product upload, banner swap, and app install is a fresh chance for an image to ship without a description. TestParty's alt text checker covers single-page auditing methods in depth; in TestParty's audits across 100+ Shopify brands, a single point-in-time scan is already stale by the next product launch.

For catalogs in the thousands, checking one image at a time doesn't work. TestParty's bulk-fix guide for Shopify product image alt text covers the CSV and Admin API methods that make a full-catalog pass practical, and Shopify alt text apps compared covers packaged tools that automate the same job. Either path still needs the human layer this reference has been building toward: a scanner tells you an attribute exists, never whether it serves the shopper in front of it.

Frequently Asked Questions

Does an empty alt attribute (`alt=""`) ever fail WCAG 1.1.1? Only if the image isn't actually decorative. `alt=""` is correct, required, for a texture, spacer, or repeated flourish. It becomes a failure the moment it's used on an image that conveys information — a shopper then gets nothing where they needed a description. The empty string is never the problem; the classification behind it is.

Is alt text required on every image on a page? Every `<img>` needs an `alt` attribute, but not every one needs descriptive text. Decorative images get `alt=""` — present, but intentionally empty — which still satisfies 1.1.1. What's never acceptable is omitting the attribute altogether, since that leaves assistive technology to guess.

Do CSS background images need alt text? They can't have one — `background-image` has no alt mechanism at all. That's fine when the background is decorative, and a violation by construction when it isn't, because information that exists only inside it is invisible to assistive technology, with no fix except moving that content into real HTML.

Does the title attribute work as a fallback for missing alt text? No. Most screen readers don't announce an image's `title` at all, and sighted keyboard users rarely see it either, since it appears only on a mouse hover delay. Treat it as an optional tooltip, never a text alternative.

How does WCAG 1.1.1 apply to SVG icons? The same purpose-based rules apply, but the mechanism differs, since SVG has no native `alt`. An informative or functional inline SVG needs `role="img"` with a `<title>`, or an `aria-label`; a decorative one needs `aria-hidden="true"` instead, removing it from the accessibility tree the way `alt=""` does for an `<img>`.

TestParty practices a cyborg approach to content: AI assists with research and drafting, our accessibility experts validate every claim. This article represents our editorial perspective based on public data as of the publication date. We compete in the digital accessibility space — which means we have informed opinions, but also a vested interest. All sources are cited so you can draw your own conclusions.