Can shoppers inspect product photos without pinching or swiping?

Identify what the viewer actually requires

A shopper enlarges a product image to check a connector, garment seam or printed specification. If the custom viewer only zooms by two-finger pinch or changes views through a precise horizontal swipe, that customer may be unable to inspect the detail. WCAG 2.2 success criterion 2.5.1 says that functionality operated by multipoint or path-based gestures must also work with a single pointer without a path-based gesture, unless the gesture is essential. The criterion concerns gestures interpreted by the web content; it does not make the shop responsible for ordinary browser or operating-system gestures. Start by identifying exactly which actions your own viewer implements.

A multipoint gesture uses more than one contact, such as spreading two fingers to zoom. A path-based gesture depends on the pointer moving along a particular path, such as flicking left across a photograph to reveal the next view. The W3C explanation contrasts those with a tap, click or similar single-pointer action that does not require tracing a path. A drag-only substitute is not a safe shortcut: WCAG 2.2 also has a separate dragging-movements requirement, so the W3C explanation explicitly notes that the alternative cannot rely exclusively on dragging. Check the result of each gesture, not just the gesture's name.

Make a function inventory for the viewer: next image, previous image, zoom in, zoom out, reset size, move around an enlarged image, open or close full screen, and read the image description. Some of these may not exist on your site; do not add controls for imaginary features. If the business offers a three-dimensional spin view, list its rotation and reset actions too. For each existing action, ask whether one tap or click on a visible control can produce the same useful result. An alternative that changes only the thumbnail while leaving the critical detail inaccessible is incomplete for the reader's decision.

Provide direct controls for the same result

For a photo sequence, put clearly named Previous image and Next image buttons near the current image. W3C technique G215 uses this pattern for a slider that otherwise responds to a horizontal swipe. Make the button state correspond to the actual first and last image; do not leave a button that appears active but silently does nothing. Show which image is current and give each photograph a useful description of what is pictured. If there are several angles, the person should know whether the next image is the back, close-up or dimensions view rather than having to infer it from a tiny dot.

For zoom, a labelled Zoom in button and Zoom out button can replicate the enlargement change without a pinch. Include a reset action if the enlarged state is otherwise hard to escape. Test whether a single-pointer user can inspect every meaningful region after zooming. If panning requires a path-based drag, offer a way to move the viewport through discrete controls, a selectable region list, or another one-pointer method that reaches the same detail. The exact interface can vary, but the workaround must be operable and not merely decorative. Also check that enlargement does not cover purchase controls or trap the user in a full-screen layer.

Do not assume that a double tap is the only viable alternative simply because it uses one finger. It can be difficult for some users and may be confused with other actions. A visible, labelled control is easier to discover and test. Position controls near the image they affect, make their active area reasonably easy to hit, and ensure they do not hide essential product detail. Target size and pointer cancellation have their own requirements; the presence of a button alone does not prove the entire interface is accessible. Here the editorial decision is narrower: every authored complex-gesture function needs a genuine non-path single-pointer route.

Be careful when a product viewer delegates some movement to the browser and implements other movement itself. Ordinary page scrolling or browser zoom is outside the authored-gesture rule, while the viewer's own pinch zoom or swipe-to-change-image is inside it. Test by asking what code changes the product view after the action. If the answer is the shop's viewer or plugin, map that function to a single-pointer control. This distinction prevents a team from spending effort trying to replace normal operating-system gestures while missing a custom swipe that actually hides the next product image from a shopper.

Work through a product decision

Imagine a retailer selling a desk lamp with four photos: front, rear connectors, control switch and dimensions. A shopper needs to see whether the rear connector fits their workspace. The swipe gesture moves between images and pinch zoom reveals the connector label. A workable alternative gives Next and Previous buttons, a current-image label, Zoom in and Zoom out controls, and a way to reach the connector region when enlarged. The shopper should be able to identify the rear view and inspect the relevant detail using only single clicks or taps. This is an illustrative design scenario, not a measurement of customer behaviour or a claim about a particular product.

Now test the negative cases. Turn off touch gestures if your test setup permits, or deliberately use only one pointer without dragging. Can you move from the first to the last photo? Can you zoom and return to a normal view? Can you reach a detail near each edge, and can you close the viewer without losing your place on the product page? Repeat at a narrow mobile width, since controls may disappear into a swipe-only layout. Repeat with a mouse because a single-pointer alternative should not depend on a touchscreen. Record the actual action and result for each function, rather than simply checking that buttons are visible.

Compare information, not just mechanics. If the pinch view contains a serial number or material finish absent from the non-gesture view, the two paths are not equivalent for a shopper who needs that detail. Sometimes the right answer is a separate high-resolution detail photo with a descriptive caption rather than a complicated panning system. This may simplify both the interface and the product decision. Keep descriptions accurate to the actual photographed product; an image caption must not invent a feature or compatibility claim. Where the image is decorative, the purchasing information should still exist in text elsewhere on the page.

Write the acceptance outcome in terms of the shopper's decision. For a product whose compatibility depends on a connector, the test passes when the person can select the connector view, enlarge or otherwise inspect the relevant region, read any essential specification in text, and return to the buying page with one-pointer actions. If the controls are present but the image remains too low resolution to verify the connector, the content itself needs work. If the detail is only visible in an image and cannot be reliably read, add accurate text from the verified product specification rather than asking customers to decipher pixels.

Test and maintain each product template

Audit the shared viewer template first, then sample products with different image counts, aspect ratios and detail placement. One-image products should not show meaningless previous and next controls. Products with many images should still communicate the current position. Portrait and landscape photos can change where the controls sit and whether an enlarged detail remains reachable. Check the viewer after theme updates, image-provider changes or new mobile breakpoints. A passing template test does not guarantee that every product's actual image sequence or description is useful, so include a few real product pages in acceptance.

If the viewer is supplied by a theme or commerce plugin, ask its maintainer which gestures it interprets and which one-pointer controls reproduce them. Do not accept a feature list alone; run the journey on the version you deploy. If the plugin cannot provide an alternative for an important detail, consider replacing that interaction or presenting the detail in an ordinary image and text. This is a product-content decision as much as a code decision: the customer needs enough evidence to choose the right item, and the business needs a maintainable way to keep that evidence available.

Before release, have a colleague unfamiliar with the viewer inspect an actual product using one finger or a mouse click at a time. Give them a concrete task, such as finding the connector or checking a seam, and observe whether they can reach the relevant view and return to the product page. Note failures by function: changing images, zooming, reaching a region or exiting. Repair the specific missing route, then repeat the task. This is a local acceptance check, not a performance claim. It shows whether the alternative supports the shopper's decision rather than merely satisfying a control inventory.