Auditing Product Images for WCAG Accessibility

Scope the audit: templates, not SKUs

The first mistake is treating a WCAG accessibility audit like a photo quality audit and trying to walk the catalogue SKU by SKU. Accessibility failures come from two different sources, and they need different sampling.

Template failures live in the theme: the gallery component, the zoom behaviour, the swatch picker, the collection grid. Fix one and it is fixed on every product. You only need to test each distinct template once, thoroughly.

Content failures live in the data: the alt text on each image record, the infographic a designer exported with grey text on white, the lifestyle shot that carries a promotional message in pixels. These vary per image and need sampling across the catalogue.

A sensible scope for a mid-sized store looks like this:

Test on at least two viewport widths. Themes routinely swap a thumbnail strip for a swipe carousel on phones, and the two are separate components with separate bugs.

The success criteria that apply to product images

WCAG 2.2 has 55 Level A and AA success criteria. About a dozen are relevant to product imagery. Knowing which ones keeps the audit short and keeps you from logging findings that are not actually failures.

Three of these (2.5.7, 2.5.8 and the focus criteria added alongside them) are new in WCAG 2.2. The European standard EN 301 549 currently points at WCAG 2.1, so they are not yet a legal requirement there, but they describe real barriers and are cheap to test while you are already on the page.

Testing text alternatives properly

A scanner tells you whether an alt attribute exists. The audit has to answer three harder questions, and each needs a human.

Is it accurate? Open each sampled image beside its alt text. Templated alt text drifts: the string says "front view" on a back shot, or names the default colour on every variant. Mark any string that describes a different image than the one shown.

Is it the right kind? WCAG treats images by role. The main product photo is informative and needs a description. A thumbnail that is a button needs a name describing what it does or shows ("View image 3: back of jacket"). A purely decorative divider needs an empty alt="" so it is skipped. An image that is the only content of a link must describe the destination. Mixing these up is a failure even when every image "has alt text".

Is it distinguishable in sequence? This is the test most audits skip. Turn on a screen reader (VoiceOver on Mac and iOS, NVDA on Windows, TalkBack on Android) and move through the gallery. If you hear the product title six times, the alt text passes a scanner and fails a person. Each image should tell the listener what this view adds: the angle, the detail, the scale reference.

Record three numbers per sample: the share of images with no alt attribute, the share with alt text that is present but wrong or duplicated, and the share that pass. The middle number is usually the largest and is invisible to automated tools.

If the sample shows the problem is volume rather than quality, the fix is a production question, covered in writing product alt text at catalogue scale.

Testing contrast: text in images, controls, and the product itself

Contrast testing on product imagery splits into three separate checks with three different thresholds. Use any colour-contrast checker with an eyedropper; sample the lightest part of the text stroke against the darkest part of what sits behind it, since text over a photo has no single background colour.

Text baked into images (1.4.3). Body-size text needs a ratio of at least 4.5:1 against its background; large text (roughly 24px regular or 19px bold and above, at the size the image is displayed) needs 3:1. Check feature callouts, comparison charts, sale badges and size guides. Remember the image is scaled down on a phone, so text that counts as "large" in the design file often is not large on screen.

Then ask whether the text should be in an image at all. Under 1.4.5, if the same presentation can be achieved with real text, it should be. A size chart as a JPEG fails on that ground regardless of its contrast, and also cannot be resized, translated or read aloud. Logos and text that is part of the product itself (a printed label, a slogan on a T-shirt) are exempt.

Controls on top of images (1.4.11). Gallery arrows, pagination dots, the zoom icon, the outline marking the selected thumbnail and the border of each colour swatch all need 3:1 against what is adjacent to them. White arrows over product photos are the classic failure: they pass on a dark lifestyle shot and vanish on a white-background packshot. Test them against your lightest and darkest images. A white swatch on a white page with no border fails the same criterion.

The product against its plate (usability). Not a conformance item, as noted above, but worth a column in the audit. Convert a sample of main images to greyscale and view them at thumbnail size. If the product's edge disappears into the background, shoppers with low vision or a phone in sunlight lose the silhouette. The fix is rarely a reshoot: a faint contact shadow, a slightly off-white plate, or a marginally darker background for pale products restores the edge without breaking a consistent catalogue look.

Testing the gallery, zoom and swatches

This is the template half of the audit, and it is where the highest-severity findings usually are. A missing alt string degrades one image; a gallery that cannot be operated from a keyboard hides every image after the first, on every product.

Put the mouse away and run this sequence on each template:

1. Tab into the gallery. Can you reach every thumbnail and both arrows? Is there a visible focus indicator on each (2.4.7)? Is the focused thumbnail hidden behind a sticky header or cookie banner?
2. Activate with Enter and Space. Does the main image change? Thumbnails built from plain div elements with click handlers fail here (2.1.1).
3. Listen to it. With a screen reader on, does each control announce a name, a role and its state, such as "Image 2 of 6, selected" (4.1.2)? Does the reader hear that the main image changed?
4. Open zoom or the lightbox. Can you open it from the keyboard, does focus move into it, does Escape close it, and does focus return to where you were?
5. Hover zoom. If a magnified panel appears on hover, 1.4.13 expects it to be dismissible without moving the pointer and to stay visible while the pointer is over it. A zoom panel that covers the product title with no way to dismiss it is a common failure for screen-magnifier users.
6. Touch. On a phone, is there a way to change image without swiping, such as arrows or dots (2.5.7), and a way to zoom without pinching, such as a double-tap or a button (2.5.1)? Are the dots at least 24 by 24 CSS pixels or spaced so their targets do not overlap (2.5.8)?
7. Motion. If the gallery advances by itself or a product video loops automatically for more than five seconds, there must be a pause control (2.2.2).
8. Swatches. Does each colour option have a text name available to assistive technology and visible somewhere on selection (1.4.1)? "Unavailable" must be conveyed by more than a faded colour.

Finally, zoom the browser to 400% at a 1280px-wide window, which is equivalent to a 320px viewport. The page should reflow to a single column. A wide size-chart image that forces horizontal scrolling of the whole page fails 1.4.10; a chart that scrolls inside its own container is acceptable.

Recording findings and ranking the fixes

An audit is only as useful as its output. Log each finding as one row with the same fields: the criterion, whether it is a template or content issue, where it occurs, how many pages or images it affects, a severity, and the owner. The template-or-content field matters most, because it decides who fixes it and how far the fix travels.

Severity should reflect what the shopper can no longer do, not how many times the scanner flagged it:

Then order the work by reach. Template blockers come first: one theme change repairs every product page at once. Text-in-image problems come second, because they are few in number, serious, and usually owned by a single designer. Alt text comes third, sequenced by revenue the same way you would sequence any other fix in a product image catalogue audit.

Keeping the catalogue compliant after the audit

Template fixes stay fixed until the next theme change. Content fixes decay from the day you finish, because new images arrive every week. The audit should end with three controls at the point where images enter the catalogue.

Alt text travels with the image. Alt text is stored on the image record in your platform, not in the file, so any workflow that re-uploads an image can silently drop it. Make alt text a required field at upload. Tools that publish images for you should set it in the same step; Retouchable, for example, sets filename, alt text and position together when it pushes a finished image to a Shopify product, so a refreshed photo does not arrive blank.

No new text in pixels. Add one line to the creative brief: size charts, care information and feature lists are built as page content, not exported as images. Where a marketplace format forces image-based callouts, the brief specifies minimum text size and contrast, and the same information is repeated in the listing text.

A plate rule for pale products. Write down how white, cream and transparent products are shot or processed, including background tone and shadow, so the edge always survives at thumbnail size. Consistency here helps every shopper, not only those with low vision.

Re-run the template tests after any theme update or gallery app change, and re-sample content quarterly. A scanner in your deployment pipeline will catch regressions in the machine-detectable items; the keyboard and screen reader pass takes under an hour per template and catches the rest. Treated that way, auditing product images for WCAG accessibility stops being a project and becomes a short recurring check.