Product images / PUBLISHING WORKFLOW
Why do gallery arrows and selected thumbnails disappear in high-contrast mode?
If a product photo remains visible but its navigation disappears in high-contrast mode, inspect the controls’ styling before replacing the photo. Forced colors can change borders, fills and shadows. Give the theme maintainer a list of controls that become indistinguishable, with their normal, focused and selected states.
Reproduce the actual display preference
Use a supported browser with an operating-system contrast theme, then record that environment. Start with the product gallery’s next arrow, previous arrow, enlargement control and thumbnails. Check whether each control has a visible boundary, recognizable purpose and visible keyboard focus. A page that looks correct in ordinary dark mode has not completed this separate test.
MDN documents that forced colors uses system colors and removes effects such as box-shadow. That explains a possible failure when a shadow is the only control boundary. It does not prove the specific cause until the maintainer inspects the actual styles.
Describe states rather than a missing brand color
In this fictional shoe gallery, the next arrow is a white shape on a translucent circle. The active thumbnail is distinguished only by a colored shadow. With the chosen contrast theme, the photograph remains present but the arrow and active-view cue become hard to find. The report concerns navigation and selection, not whether the merchant’s accent hue survives.
| Control state | Normal view | Contrast-theme observation |
|---|---|---|
| Next arrow | Visible circular control | Boundary and icon merge |
| Current thumbnail | Colored shadow | Selection cue disappears |
| Keyboard focus | Visible outline | Check separately from selection |
Focus and the current gallery selection can be on different thumbnails. Test four meaningful observations: selected but unfocused, focused but unselected, focused and selected, and an inactive ordinary option. If both cues collapse into the same border, a shopper may know where the keyboard is but not which view is displayed. Record the actual states rather than ask only whether the brand color survived.
Request targeted control styling
Ask the maintainer to use reliable boundaries and suitable system-color treatment where the current style fails. Native control semantics also matter to browser color handling. Keep focused and selected states distinguishable, and do not rely on a gradient or shadow as their only signal. Test a narrow gallery where controls sit over the photograph as well as a separate navigation bar.
Avoid disabling forced-color adjustment across the entire page to preserve brand styling. MDN recommends targeted usability changes. If a specific exception is proposed, have an accessibility reviewer examine the consequence for text, controls and user preferences.
For an over-photo control, inspect its icon and boundary on both light and dark areas of the actual image under the chosen system theme. A repaired border on one pale product may disappear on another background. Keep native semantics, focused state and selected state in the review; a CSS media-query match alone does not prove usable control contrast.
Complete the view-selection task
With the contrast theme still enabled, ask a reviewer to reach a detail view, identify its selected thumbnail and return to the front. Record the exact controls used and the visible focus at each step. Repeat ordinary display mode after repair so the adjustment does not hide the same control elsewhere.
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 provide approved photos but does not implement system-color CSS or audit an external store. This check verifies a particular navigation task and environment; it does not establish complete accessibility or predict conversions.
Record the OS contrast theme, browser and controls tested, with the observed focus and current view. This is an environment-specific task check, not complete WCAG conformance. Recheck truthful selected-option semantics and the keyboard inspection route after styling changes.
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 forced-color environment and separate focused/selected control visibility. Keep review_status pending until the actual check is performed.
Sources and further reading
Recorded source-review dates are listed individually below. An undated source does not inherit the article’s publication date. Software and platform rules can change; check the current original before acting.
- CartVisual: editorial scope and evidence policy · Review date not separately recorded
- MDN: forced colors and system control colors · Reviewed
Frequently asked questions
Is this the same as testing dark mode?
No. Forced colors is a separate user preference with different browser styling behavior.
Should I disable high-contrast adjustments to keep branding?
Avoid a blanket override; review small, justified usability repairs.
Can an image export fix an invisible focus outline?
No. The theme’s control styling and behavior need inspection.
PREPARE ASSETS FOR YOUR NEXT STEP
Create supporting product assets in CartVisual.
Create new product creative assets in the workspace, then continue in your chosen tools. Third-party software procedures described in this guide take place in those applications; this workspace link does not imply an integration. Check current capabilities, account access and credit quotes.
Explore asset creation tools Check pricing and credits