Making Product Image Galleries and Zoom Accessible
A product page’s image gallery — a strip of thumbnails that swap the main photo, a click-to-zoom or magnifier overlay for detail shots — is one of the most custom-built pieces of UI on an e-commerce site. Almost nothing about it is a native HTML control, which makes it one of the most common places accessibility support has to be built in deliberately, since there’s no default browser behavior doing that work automatically.
Quick answer: three things break most often. Thumbnail selectors need an accessible name per thumbnail and a way to tell which one is selected, not just a visual highlight (WCAG 4.1.2 and 1.3.1). Zoom/lightbox overlays need to be operable entirely by keyboard and contain focus without trapping it — Escape has to close the overlay and return focus to where the shopper started (WCAG 2.1.1, 2.1.2, 2.4.3). And when a shopper zooms the page (not the product image) to 400%, everything around the zoomed photo — close button, arrow controls, thumbnail strip — has to stay reachable without scrolling in two directions (WCAG 1.4.10 Reflow); the zoomed photo’s own content is the one part of this UI that gets an explicit exception.
This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.1 AA requires for gallery and zoom UI and how to meet it, not whether a specific site carries legal risk.
Thumbnail selectors: give each one a real accessible name and a selected state
A typical gallery renders four to eight small thumbnail images down the side or below the main photo; clicking one swaps the large image. Visually, the active thumbnail usually gets a border or highlight. Read by a screen reader, a row of <img> or <button> elements with no distinguishing text is often announced as “button, button, button, button” — identical, with no indication of which one is currently showing.
Give each thumbnail a real accessible name. If the images are different product angles or colors, name them accordingly — aria-label="View front angle", aria-label="View in Navy" — rather than leaving the accessible name to fall back to generic alt text or nothing at all. This is the same underlying requirement as WCAG 1.1.1 Non-text Content, covered more generally in our alt-text article, applied to a case that piece doesn’t get into: thumbnails are functional controls, not illustrative images, so their accessible name should describe what selecting them does, the same rule that already governs icon buttons.
Mark which thumbnail is currently selected, programmatically, not just visually. A CSS border-highlight conveys nothing to a screen reader. Add aria-current="true" to the active thumbnail (removing it from the others as selection changes) so assistive technology can determine the current state the same way a sighted shopper sees it. This satisfies WCAG 4.1.2 Name, Role, Value (A) — a component’s state has to be programmatically determinable and update the moment it actually changes.
Group the thumbnails so their relationship is clear. Wrap the strip in a container with role="group" and an aria-label identifying it (“Product images”), satisfying WCAG 1.3.1 Info and Relationships (A) the same way a filter facet’s fieldset/legend does — a screen reader user tabbing in should hear they’ve entered a set of image options, not a run of unrelated buttons with no context.
Zoom and lightbox overlays: contain focus, don’t trap it
Clicking or hovering a product photo often opens either an in-place magnifier or a full-screen lightbox overlay. Both need to be operable without a mouse, and the full-screen case has a specific keyboard-focus requirement that’s easy to get half right.
Every trigger and control needs to work from the keyboard. WCAG 2.1.1 Keyboard (A) requires that “all functionality of the content is operable through a keyboard interface” — the zoom trigger, the lightbox’s next/previous arrows, and its close control all need to receive focus and activate on Enter or Space, the same as any other interactive element. A zoom icon built as a <div> with a click handler and no tabindex is invisible to keyboard navigation entirely — a mouse user can open it, a keyboard user can’t.
When the lightbox opens, focus has to move into it — and stay contained there without trapping it. This is the distinction between correct modal behavior and WCAG 2.1.2 No Keyboard Trap (A). The WAI-ARIA APG Dialog (Modal) Pattern specifies the behavior concretely: when the dialog opens, focus moves to an element inside it; Tab and Shift+Tab cycle within the dialog’s own tabbable elements without ever landing on page content underneath; and Escape closes the dialog. The failure 2.1.2 is named for happens when a dialog contains Tab correctly but leaves out Escape (or any other exit method) — focus moves around inside the overlay, but a keyboard user has no way out of it. A correctly built lightbox satisfies 2.1.2 specifically because Escape is a working exit.
Focus has to return to where it started when the overlay closes. WCAG 2.4.3 Focus Order (A) requires that navigation order preserve meaning and operability — for a lightbox, closing it (via Escape or the close button) should return keyboard focus to the thumbnail or main image that opened it, not the top of the page or nowhere in particular. Losing focus to the page body on close forces a keyboard user to re-navigate from scratch to find their place again, on every close.
Reflow: the zoomed photo is exempt, the lightbox chrome isn’t
WCAG 1.4.10 Reflow (AA) requires that content be usable at a 400% browser zoom (equivalent to a 320 CSS-pixel-wide viewport) without forcing the user to scroll in two directions — vertical scrolling to read a long page is fine, but having to scroll both down and sideways to read a line of text or reach a control isn’t. This applies to a browser-level zoom (a low-vision user enlarging the whole page), a separate thing from a product image’s own pinch-to-zoom or magnifier feature.
The standard carries an explicit, narrow exception for content that “requires two-dimensional layout for usage or meaning” — its own examples are maps and diagrams, and a zoomed-in product photo (a fabric close-up a shopper pans around to see stitching detail) reasonably fits the same category: panning a magnified image in two directions is the feature working as intended, not a reflow failure. That exception covers the zoomed image content itself — it does not cover the interface around it. The lightbox’s close button, next/previous navigation, and thumbnail strip are ordinary UI controls, not content requiring two-dimensional layout, and all need to stay reachable at 400% zoom without forcing horizontal scrolling to find them.
Where to start
In rough order of effort: add aria-label naming what each thumbnail selects (minutes per gallery), add aria-current="true" to the active thumbnail and keep it in sync on selection (a small state-management change, not a redesign), and confirm the lightbox’s open/close/arrow controls all work with Tab, Enter, and Escape alone, with the mouse unplugged — including that Escape returns focus to the trigger element rather than dropping it. None of this requires touching the zoomed-image pan-and-magnify behavior itself.
FAQ
Does the zoomed product image itself need to avoid two-directional scrolling? No — WCAG 1.4.10 Reflow has an explicit exception for content requiring two-dimensional layout for its meaning or use, and a magnified image a shopper pans around to see detail is a reasonable fit. The controls around it (close, navigation, thumbnails) don’t get that exception and still need to reflow.
Is a full-screen lightbox required, or can zoom work in-place on the page? WCAG doesn’t require either pattern. An in-place magnifier that never removes focus from the page context avoids the modal-focus requirements above entirely, since there’s no dialog to contain focus in. A full-screen lightbox is a common pattern, not a mandate — either is fine as long as it meets the keyboard and focus requirements for what it actually is.
What’s the difference between “focus is contained” and “focus is trapped”? Containment plus a working exit method (Escape, or a clearly indicated alternative) is correct modal behavior, per the WAI-ARIA APG Dialog pattern. A trap is containment without a working exit — focus moves inside the component, but there’s no keyboard-only way to leave it. The difference is entirely whether Escape (or an equivalent) actually works, not whether Tab is contained.
Get a full audit of your product-page UI
This covers the failure patterns most specific to image galleries and zoom — a full Quietramp audit checks your whole site against WCAG 2.1 AA, verified by a person operating it with a keyboard and screen reader, not just an automated scan. See a real sample report of what that looks like, or check pricing — $890 one-time, $99/month if you want ongoing re-checks after fixes ship.
This is educational content about technical accessibility standards, not legal advice. Meeting WCAG 2.1 AA does not guarantee legal compliance with the ADA or any other law, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.
This article was drafted with AI assistance and reviewed by a person for accuracy before publication.