Learn / Fixes
How to make variant pickers agent accessible
A variant picker fails an agent when the options only exist after a script attaches them, or when selecting one requires a hover. Both leave an agent at a product it wants and unable to say which version it wants, which is the most expensive place to fail because everything before it succeeded. Most of the remedy is ordinary accessibility work you may already owe.
A variant picker fails an agent in two ways: the options only exist after a script attaches them, or choosing one requires a hover. Either way the agent reaches a product it wants and cannot say which version it wants.
This is the most expensive class of failure in the whole journey, because everything before it worked. You were found, read and chosen, and then the sale ended at a dropdown. See hover only variant picker and variant js required.
The accessibility shortcut
An agent and a keyboard user need almost exactly the same things. If your picker works for somebody navigating with a keyboard and a screen reader, it very probably works for an agent.
- Real form controls, a select or radio inputs, rather than divs with click handlers.
- Every option present in the served markup with a text label, not built client side.
- Selection reachable without a pointer, so no hover only reveal.
- Availability per option, so an unavailable size is identifiable as unavailable rather than merely not working.
That is the whole list, and none of it dictates how the picker looks.
Publish the matrix, do not compute it
The commonest modern version of this failure is a picker that fetches the variant matrix from an API after load. The page renders, the options appear, and to anything that read the markup and stopped there the product has no variants at all.
Render the matrix into the page or publish it as structured data alongside per variant price and availability. See how to expose stock availability to agents.
Test it the way it fails
Disable JavaScript and open a product with several variants. Can you tell which options exist? Can you tell which are in stock? Then, with scripts enabled, try to select an option using only the keyboard.
If either test fails, the fix is usually contained to one component, and it also settles an accessibility obligation you have anyway.
Questions
If my picker is keyboard accessible, is it agent accessible?
Largely yes, and that is the useful shortcut here. An agent and a keyboard user need the same things: real form controls, options present in the markup, and state that changes without a pointer. Accessibility work you already owe fixes most of this.
What about swatches that show a colour rather than a name?
A colour with no accessible name is unusable to an agent asked for a black jacket. The swatch can stay visual as long as each option carries the name as text.
Do I need every combination in the markup?
You need the options and their availability to be determinable without executing your page. For most stores that means rendering the variant matrix into the markup or publishing it as structured data, rather than building it client side from an API call.