There is a version of this project where you audit the new site, find forty things, and tell everyone the migration broke them. Some of it will be true. Some of those forty were there for years, and nobody can tell which is which, because nobody measured the old site while it still existed.
That distinction is not academic. A regression is a defect somebody introduced, which usually means somebody has to own it and fix it in this sprint. A pre-existing problem is a backlog item. Getting those two piles right is what makes a post-migration report useful rather than inflammatory, and the only way to get them right is to record a before.
So this page has two halves. What to capture while the old site is still up, and what to compare once the new one is live. If you have already switched over, skip to the last section, which covers what can honestly be said when the before is gone.
Why a Migration Breaks Accessibility Specifically
Content survives a migration because it is what everyone is watching. Accessibility rides along on things nobody thinks of as content, and those are what fall off.
Alt text lives in a database field, and whether it arrives depends on whether somebody mapped that field. Heading levels live in markup that gets rewritten when rich text is converted. Table headers survive as th or become td depending on the parser. The lang attribute lives in a template. Focus styles live in CSS that got replaced wholesale. Form labels live in a component library nobody rebuilt from the old one.
W3C's own maintenance guidance names the pattern. It advises that reviews should identify not just the issues but why they are occurring, and among the questions it suggests asking is whether problems arose as a result of a change in the content management system. That guidance was last updated in 2016 and it has aged well, because the failure mode has not changed.
What to Capture Before You Switch
This is the half people skip, and it is the cheap half. None of it needs an audit. It needs somebody spending an afternoon recording what currently exists, so there is something to compare against later.
| What to record | How | What it proves later |
|---|---|---|
| A scan of the same URL set | Any consistent tool, with the date and version noted | Machine-checkable findings on both sides, compared like for like |
| Alt text on a sampled set of images | Export the field, or record the pairs by hand | Whether descriptions survived the field mapping |
| Heading outline per template | The heading structure checker, one page per template | Whether the rewrite flattened or renumbered headings |
| Form labels and error text | Screenshots plus the accessible names | Whether the new component library kept the associations |
| Focus styles | A keyboard pass, recorded | Whether the new theme kept a visible focus indicator |
| Language attributes | View source on one page per language | Whether the template still declares its language |
| Skip link and landmark structure | Tab once from the top, then list the landmarks | Whether the bypass route survived |
| Named journeys, end to end | A keyboard run through each complete process | Whether the process still completes at all |
| Document links | A crawl of PDF and Office links | Whether files moved, broke or were regenerated |
| Responsive layouts per template | Each breakpoint the site ships | Each variation has to conform on its own, so each is a comparison |
Do not write up a missing skip link on its own
A skip link is one of two sufficient routes for the bypass rule. Correctly ordered headings and landmark structure are the other. So a new theme that dropped the skip link has only broken something if it also lost the headings and landmarks, and a report that files it as an automatic failure will be argued down by the first developer who checks. Test both routes, then report what is actually missing.
The Field Mapping Is Where Alt Text Goes to Die
Most migration tooling maps content fields, because content is what stakeholders see. Accessibility payloads live in fields nobody demos, and each one needs its own line in the mapping document.
- Image alt text, which in some systems is a property of the media library item and in others a property of the place it was used. Those two behave completely differently on migration, and the second one is the one that survives.
- Decorative flags, meaning whichever field records that an image is decoration. If it does not map, every decorative image arrives either unlabelled or labelled with a filename.
- Link text, where a system that stores a title separately from the anchor text can produce a site full of links called Read more.
- Table headers, including which row or column was the header and whether a scope was set.
- Caption and transcript fields on video, which often live in a different subsystem entirely.
- Document titles on PDFs, which decide what a screen reader announces when the file opens.
Write those six into the mapping spreadsheet next to the body copy and the migration team will handle them, because they handle what is on the list. Leave them off and no amount of testing afterwards recovers descriptions that were never carried over.
Comparing the Two Sides Without Fooling Yourself
A comparison is only as honest as its sample, and the temptation is to compare the pages that look most similar. WCAG-EM has a better instinct. Build a structured sample covering the common views, the essential functionality and the technologies relied upon, then add a random set sized at a tenth of it, on top rather than carved out. If the random pages show problems the structured ones did not, the structured sample was not representative and you widen it.
Two more rules keep the comparison meaningful. Compare the same URLs wherever the URLs survived, and where they did not, compare the same template rather than whatever the redirect landed on. And compare each responsive layout separately, because a full page includes every variation the page automatically presents for different screen sizes and each one has to conform on its own. A template swap is several comparisons, not one.
Then there are the journeys. Complete processes conform as a whole or not at all, so a migrated checkout, signup or booking gets run end to end on both sides rather than sampled page by page. That is the comparison most likely to find something expensive, and the one most likely to be left until after launch.
When the Old Site Is Already Gone
This happens more often than not, because accessibility gets thought about after the switch rather than before it. The work is still worth doing. The claim is what changes.
What you can honestly say is that the new site has these findings, at this date, on these pages. What you cannot say is that the migration caused any of them, and a report that asserts causation without a before is making a claim it cannot support. Somebody will eventually check, and it will be the one finding that was there in 2019.
There is a partial route. Archived copies, staging environments and old screenshots can establish specific facts, such as whether a particular image once had a description. Treat each of those as evidence about one thing rather than a baseline for the whole site, and say in the report where the evidence came from and what it covers.
The other thing worth doing at this point is forward-looking. W3C's maintenance guidance suggests keeping a baseline list of the browsers and assistive technologies you support and updating it as versions change, which is exactly the kind of thing a replatform is a good moment to write down. Our keeping it accessible guide covers the rest of that process.
What None of This Obliges You to Buy
No standard sets an audit interval. W3C's guidance recommends review across change, which is a sensible instinct rather than a schedule, and nothing in WCAG requires an annual anything. If somebody quotes you a subscription on the basis that the standard demands one, ask which clause.
What the change genuinely justifies is checking what changed. A replatform touches every template at once, which is the single biggest accessibility event most sites ever have, and it is the moment where a fix is still one commit rather than a retrofit across a thousand pages.
One honest limit
We audit and never repair, so we will not be doing your migration or fixing what it broke. If the old site is already down we will say so in the report and describe the new site rather than inventing a cause. Where a before exists, the comparison is the deliverable. Scope it at contact or read what the post-migration audit covers.