How should a Shopify store protect accessibility during a theme redesign?

A redesign resets accessibility to whatever the new theme ships with, which is usually worse than what you had. Freeze a baseline of the old store, write accessibility into the design brief, test the new templates before launch, and keep monitoring through the cutover so regressions surface in days, not months.

Freeze a baseline of the old store first

Before the redesign starts, capture where accessibility stands: a full automated scan of every template, the open issues with owners, and the manual test notes for the money path. This baseline is the bar the new design has to clear. Without it, nobody can say whether the redesign improved or degraded anything, and the conversation becomes opinion instead of evidence.

Also record which fixes were custom. Years of remediation live in the old theme's code: repaired focus states, labeled forms, fixed heading order. Redesigns routinely discard these because the new theme starts from a stock template. Inventory the custom fixes so the new build re-implements them deliberately instead of rediscovering the same barriers from customer complaints.

Write accessibility into the design brief, not the QA phase

The brief should name the standard: WCAG 2.2 Level AA across all templates, keyboard operability for every interactive component, visible focus, sufficient contrast in the brand palette, and forms with real labels and announced errors. When these requirements arrive with the designs, designers pick accessible components from the start. When they arrive in QA, they become rework that the launch timeline cannot absorb.

Review the palette and type scale early. Low-contrast brand colors baked into a design system propagate to every template, and fixing contrast after launch means restyling the whole store. A designer handed contrast ratios up front simply picks compliant colors. The cheapest accessibility fix is the one made in Figma.

Test the new templates before they carry traffic

Every new template gets tested before launch: automated scan, keyboard walkthrough, and a screen reader pass over at least the product, cart, and checkout-adjacent pages. New components are where the worst barriers hide, carousels, quick-view modals, mega menus, sticky filters, because stock theme components ship with accessibility bugs the demo never showed.

Test with the apps installed, not without them. A redesign usually reshuffles the app stack too, and the interaction between a new theme and an old review widget is a classic source of launch-week regressions. The store customers see on day one is theme plus apps plus content, so that is the combination to test.

Do not go dark on monitoring during the cutover

The weeks around launch are when monitoring matters most. Keep scans running on the old store until the cutover, then point them at the new theme immediately and run the first scan within 24 hours of launch. Compare against the frozen baseline: new failures are launch regressions with a known cause, and the earlier you find them, the cheaper the fix, because the developers are still in the project and the code is still fresh in their heads.

Watch the metrics that indicate breakage beyond the scans: checkout completion by device, support tickets mentioning usability, rage clicks on the new navigation. A barrier that blocks keyboard users will not show up in revenue the first week, but it will show up in behavior signals if you look.

Schedule the first post-launch review at 30 days

Thirty days after launch, run the full review: scan diff against baseline, manual spot checks on the changed flows, and a check of everything the new apps inject. By day 30 the launch dust has settled, the urgent fixes are in, and what remains is the real state of the redesign. Document it as the new baseline, with the launch comparison attached.

This review also closes the accountability loop with the redesign team. If the new store is cleaner than the old one, the evidence proves the investment worked. If it regressed, the findings are specific enough to assign. Either way, the store leaves the redesign with a known accessibility state instead of a hope, which is the difference a watch makes.