WooCommerce Color Swatches Land in 10.9 Beta Today

For roughly a decade, every WooCommerce store that sold t-shirts, sneakers, paint, fabric, or anything with a visual variation needed a third-party swatches plugin. Some were excellent. Some were a JavaScript landmine that broke every other WooCommerce release. I have rescued enough stores from a half-working swatch plugin that I can tell you the exact shape of the problem: the plugin lives outside the data model, hooks into the variation UI, and the moment a core block changes, you are debugging someone else’s render layer at 2am.

That is why the news from Porto on June 3 mattered more than the headline suggested. WooCommerce is finally bringing color and image swatches into core, as a first-class attribute type, not as a styling layer bolted on top of a text dropdown. As of today, June 8, that work lands in WooCommerce 10.9 beta 1, behind a feature flag, available to test against block themes.

This is the kind of change I have been waiting for. Not because swatches are exciting on their own, but because moving them into the data model is the difference between a feature you depend on and a feature you patch around.

What is actually new

WooCommerce 10.9 introduces a new product attribute type called Color / Image, registered internally as wc-visual. The wc- prefix is deliberate, to avoid clashing with custom attribute types already registered by existing swatch plugins, as the WooCommerce team explains in the announcement post on the WooCommerce developer blog.

The mechanics are simple. Under Products → Attributes you can now create an attribute and pick the Color / Image type. Per term you either choose a HEX color or upload an image from the Media library. The image option matters more than people think — patterned fabrics, marble, wood grain, and printed designs are not representable as a single HEX value, and most legacy swatch plugins treated images as a paid upgrade.

Once the attribute is configured, the swatches render automatically in several existing WooCommerce blocks: the Variation Selector inside Add to Cart + Options, Filter by Attribute, the List block inside Product Filters, and the Chips block. Each swatch appears as a circle showing the HEX color or the uploaded image. There is no separate “swatches block” to add to your template — the existing blocks become swatch-aware whenever the underlying attribute is the Color / Image type.

To enable any of this, you go to WooCommerce → Settings → Advanced → Features and toggle Color swatches for attributes. It is opt-in, gated behind that flag, and per the developer blog it is currently scoped to block themes only. Classic themes are not on the list for the 10.9 release.

The timing is on schedule. According to the WooCommerce release schedule documentation, beta 1 lands one week after feature freeze. Feature freeze for 10.9 happened June 1, which puts beta 1 on June 8 — today. The previous release, WooCommerce 10.8.0 on May 26, raised the minimum WordPress requirement to 6.9 and brought the post-purchase review request email and a security fix for guest order fulfilment over the REST API. 10.9 is the cycle where the visible UX work shows up.

Why it matters for WordPress and WooCommerce people

The interesting story here is not “WooCommerce caught up with the swatch plugins”. The interesting story is what happens when a feature that lived in the plugin ecosystem becomes part of the platform.

Three things change.

One, the data model is now stable. If you build a headless frontend on top of the Store API, or you sync products to an ERP, or you feed product attributes into a recommendation engine, the swatch metadata used to live in a different shape in every swatch plugin. Now there is one shape, owned by core, and it will not disappear when the client switches themes or upgrades hosting. That alone is worth the migration cost.

Two, the variation UX stops being a JavaScript negotiation. Third-party swatch plugins usually replace the native variation dropdown by intercepting the DOM, then reattach their own click handlers, then fight whatever the theme is doing with the Add to Cart block. When the core blocks render swatches natively, that whole layer of fragility goes away. For agencies, this is the kind of dependency you stop having to plan around.

Three, accessibility and performance become core’s problem. Most legacy swatch plugins ship their own CSS, their own keyboard handling, and frequently no real screen reader story. When this work lives in the Variation Selector and Filter by Attribute blocks, it inherits whatever accessibility and Interactivity API work core has already done. The announcement does not yet detail the accessibility model, and that is something I want to test carefully in beta — but the structural answer is better than “every site has a different swatch plugin with a different a11y story”.

There is a real caveat. Block themes only, for now. If your store still runs a classic theme — and a lot of legitimate, profitable stores still do, especially in B2B — you are not in the 10.9 audience for this. You wait, or you start the block theme migration conversation that was probably already overdue.

What I would do (or not do) about it

If you are running a production WooCommerce store, do not touch the feature flag on live. That part is not interesting advice, but it needs saying because someone will. Beta 1 is a beta, and it is gated for a reason.

What I would actually do this week:

• Stand up a staging copy of the store with WooCommerce 10.9 beta 1 from the official WooCommerce GitHub releases, switch to a block theme if you are not already on one, and enable the Color swatches for attributes flag.
• Create a Color / Image attribute on a representative product — ideally one that today depends on a third-party swatch plugin — and compare the variation flow, the filter behaviour, and the chips display.
• Check the data shape via the Store API and the REST API. If you are headless, this is the part that matters more than the visual. The schema for wc-visual is what your frontend will end up depending on.
• Test screen reader and keyboard behaviour with NVDA or VoiceOver. Do not assume. The structural improvements are real, but accessibility is something you confirm, not something you trust.
• If you maintain a swatch plugin or a theme that overrides the variation selector, read the source for the wc-visual attribute type now. Decide whether you defer to core when the flag is on, or whether you keep your own rendering path. Either is defensible; both deliberate.

What I would not do: announce to clients that swatches are now native. The flag is experimental, scoped to block themes, and the data shape may still shift before 10.9 final. Tell the client the work is coming, set the expectation, and earmark the migration off their current swatch plugin as a Q3 project, not a Q2 surprise.

This is one of those quiet WooCommerce changes that does not look like a headline feature but rewires a chunk of the variation UI for the next decade. That is usually the WordPress pattern: the boring move into core is the move that compounds. I would rather have that than another flashy launch I cannot depend on next year.