How should a brand re-verify accessibility after a Shopify theme migration?

Treat the new theme as a brand-new site: re-run the full check on every template it renders, confirm that every accessibility fix from the old theme carried over, and re-verify every app and integration against the new markup. A migration resets the clock on your accessibility evidence.

Inventory the new template set first

A new theme renders pages differently: new template files, new section structure, and often new pages the old theme did not have. List every template in the new theme, homepage, collection, product, cart, checkout touchpoints, search, account pages, blog, policy pages, and any landing templates, and mark which ones changed. This list is the test plan. Anything not on it does not get tested, so it needs to be complete.

Confirm every old fix carried over

The most common migration regression is a fix that lived in the old theme's code and never made it into the new one. Take the remediation log from the old theme and check each item against the new templates: labels, focus styles, contrast corrections, skip links, error message patterns, ARIA on interactive components. Rebuild what is missing before launch. This comparison is worth doing even for themes from the same developer, because section rewrites routinely drop customizations.

Run the full check on the new markup

New themes have new code, so old evidence does not apply. Run the standard checks on every template: keyboard access through the whole flow, visible focus, names and labels on every control, focus management in modals and the cart drawer, contrast on text over the new color system, and form error handling. Do this in the theme preview before it goes live, because post-launch fixes compete with everything else that broke in the migration.

Re-verify apps and integrations

Apps that injected into the old theme's markup may render differently, or not at all, in the new one. Check each customer-facing app on the pages it touches: reviews, chat, loyalty, search, upsells. An app that looks fine but lost its accessible label pattern is a silent regression. Vendor-hosted components like payment buttons and checkout extensions deserve the same attention, because migration sometimes changes which components render where.

Reset the evidence baseline and the monitoring scope

Archive the old theme's accessibility records with a date, and start a fresh baseline for the new theme: the finding list, the retest results, the dates. Point monitoring at the new templates, including any new pages the migration added, and retire checks against URLs that no longer exist. A monitoring setup that still checks the old template list gives a false clean bill of health for the new site.