Re-baselining accessibility after a headless replatform: the 30-day audit plan

A headless replatform changes every template, component, and interaction on your store, which means your old accessibility baseline no longer applies. Re-baseline in the first 30 days: audit the new templates against the old scores, fix regressions before they become the new normal, and document the new baseline for the team that inherits it.

Your old baseline is gone

The day a headless storefront goes live, every accessibility score, audit report, and VPAT from the old theme becomes history. The new frontend is new code: new templates, new components, new JavaScript, new interaction patterns. Some of it will be more accessible than what it replaced. Some of it will be worse. Until you measure, you are guessing.

Teams skip the re-baseline because the launch itself consumed all the QA budget. Accessibility testing gets deferred to someday, and someday never comes. Six months later, a demand letter arrives citing barriers that have existed since launch day, and the team discovers the baseline was never established. The 30-day plan exists to prevent exactly this.

Week one: template coverage

Audit every template in the new storefront, not just the homepage. Headless builds tend to get the homepage right and let secondary templates drift: the search results page, the account pages, the 404, the password page. Run automated scans across the full template set and log the scores per template, so regressions are visible by page type.

Compare against the old storefront's last scores where they exist. The comparison does not need to be perfect to be useful. If the old collection template scored 95 and the new one scores 78, something regressed, and you want to know before the template ships its ten-thousandth pageview.

Week two: interaction testing

Automated scans miss the interactions that headless storefronts are built on: the cart drawer, the predictive search, the filter system, the checkout handoff. Week two is manual keyboard testing of every interactive component, with a screen reader pass on the critical paths. This is the week that finds the focus traps and the silent state changes.

Prioritize by traffic. The cart drawer and search affect more shoppers than the account address book. Work down the list until the remaining components are low-traffic enough to schedule normally. Document each finding with the template, the component, and the WCAG criterion, because this documentation becomes the regression test suite.

Week three: fix the regressions

Not everything, just the regressions: the things that worked on the old storefront and broke in the new one. Regressions are the highest-priority fixes because they represent accessibility you already had and lost. They are also usually the easiest to fix, because the old implementation shows what correct looked like.

New issues, things that were broken before and are still broken, go into the normal backlog. This distinction matters for team morale and for stakeholder communication. Week three is about restoring parity, not achieving perfection.

Week four: document the new baseline

Write it down: per-template scores, known issues with owners and dates, the manual test checklist, and the monitoring cadence going forward. The baseline document is what the next team, the next agency, and the next audit will work from. A replatform without a baseline document is a replatform that will need to be re-audited from scratch.

Set up continuous monitoring before the 30 days end. Headless storefronts change constantly, and without monitoring the baseline decays. The team that re-baselines once and never checks again is back where it started within a quarter. The baseline is not a report. It is a practice.