Why can desktop shoppers see a second product view that phone shoppers cannot?

Identify the hidden buying answer

Choose a product whose secondary photo answers a specific question, such as whether a bag has an exterior pocket. On desktop, note the action that reveals that photo. On a real phone, begin from a fresh visit and find the same answer without relying on knowledge gained from the desktop session.

This exercise concerns discovery of an existing alternate view. It is different from a tooltip explaining a feature or a zoom gesture enlarging one image. W3C’s carousel guidance supports operable navigation; it does not prescribe one universal ecommerce gallery design.

Describe the phone failure precisely

In this fictional store, the front of a tote appears by default and its zippered rear appears on mouse hover. On a phone, one tap goes straight to the product page, where the rear view is also missing from the visible gallery controls. A shopper cannot verify the rear pocket even though the merchant already owns an approved photograph.

Choose an explicit discovery route

Ask the theme maintainer to put the alternate photograph in the actual product gallery and expose a clear thumbnail or next-view control. A card may link to that gallery instead of reproducing every interaction. Agree which action navigates to a product and which changes a photo, so a first tap does not silently do something different from its visible promise.

Keep a neutral default view when no secondary image exists. Do not invent a rear angle from a front-only reference to fill a hover slot. For each source photograph, retain its approved product and variant association in the handoff.

A product card does not need to reproduce a full gallery to make the rear view reachable. It can provide an honest, visible route to a detail page whose gallery contains that view. Record the card action and the final gallery control separately. A hover animation is an optional extra, not evidence that a touch user can find the same buying answer.

Verify first-time discovery

Give a reviewer the phone page and ask them to find the rear pocket without showing them the answer first. Record the control they used and whether it also works with the keyboard. Check that switching views does not accidentally change the selected variant or add an item to the cart.

Use the gallery interaction review as a manual review record. Sample rows are fictional. It does not connect to, import into or modify an external store or production machine.

CartVisual can prepare additional images only within the supplied reference evidence, with human product review. Adding those files to your store and giving shoppers a reliable discovery route remains a separate theme and merchandising task.

For the exercise, write the starting page, visible tap target, resulting page/view and unaided answer about the rear pocket. If a reviewer has already seen the desktop answer, record that prior exposure and use another first-time reviewer when needed. This is a small editorial navigation check, not a measured discovery rate or conversion study.

Repeat keyboard enlargement and return only after the view is reachable. If the phone reaches a different product image despite the correct selected option, investigate source-to-state mapping instead of treating it as a discovery failure.

The shared gallery CSV currently contains only two fictional pending examples: keyboard-dialog return and mobile-source selection. It is a reusable column template, not coverage of every test here. Copy a row, replace its page/variant/view and test_condition with your actual case, and use observed_result for the actual tap/navigation path and whether the requested view was found. Keep review_status pending until the actual check is performed.