Can shoppers tell which color is selected and which option is unavailable?

Ask three questions for each option

Can the shopper identify the option? Can they determine whether it is currently selected? Can they understand and act on its availability? Record those answers independently. “Blue” as a generic image description may be inadequate when the actual sellable choices are Navy and Sky. Use the approved merchandising names without claiming that the swatch matches every physical display.

W3C’s radio-group pattern describes named choices with one checked value and defined keyboard behavior. A maintainer should use semantics suited to the real control design; adding several conflicting roles is not a substitute for choosing a coherent pattern.

Build a state truth table

In this fictional cushion store, Linen is selected, Moss is selectable and Clay is sold out. The visual interface distinguishes them, but a screen reader calls all three “button.” A shopper cannot infer the selected product from those names. The merchant’s report should pair approved labels with the intended behavior, without editing inventory through the review sheet.

Give the maintainer the control contract

Ask the maintainer to inspect each control’s accessible name, role and actual selected or checked state. Have them explain how unavailable choices remain understandable under the chosen design. An unavailable item may be nonselectable or may expose an explanation; whichever route is used, it must not silently add a different available variant to the cart.

Test the relevant keyboard interaction, then confirm that the approved visible label agrees with the spoken name. Repeat after changing size, because availability may depend on another option. Do not hard-code a universal arrow-key rule without knowing the control pattern.

For an implemented radio-group design, W3C describes a named group, checked state and its radio keyboard behavior; test that pattern rather than importing a button or tab interaction by assumption. Native and custom controls still need a coherent implementation. A selected state records the chosen option; it does not by itself confirm availability for the selected size or quantity.

Retest selection through purchase

Select Moss, inspect the resulting product identity and continue to the cart summary. Then examine Clay’s explanation without completing a purchase. Record the selected item and unavailable route separately. This check concerns the control’s name and state; a separate update-timing test is needed for delayed image or stock messages.

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 help produce reviewed merchandise photos and accompanying option wording. It does not set radio semantics, inventory states or external cart behavior. Keep the source imagery, control repair and actual store inventory under their respective owners.

Record the option name, actual role, selected/checked state, availability explanation and resulting cart option as separate observations. If Clay is intentionally nonselectable, verify that its reason remains discoverable under that design. If it can be selected to show an explanation, verify that doing so never silently substitutes Moss in the cart. Do not complete a purchase as part of this exercise.

Test late update feedback separately, and focus/selection visibility under forced colors without relying on hue alone.

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 name, role, state, availability explanation and cart identity. Keep review_status pending until the actual check is performed.