Keeping WCAG and ADA Accessibility Intact Through a CMS Migration
Four weeks before a replatform goes live, procurement forwards a vendor questionnaire with one line highlighted: a VPAT Report and confirm WCAG 2.1 AA conformance for the new site. The old site passed an accessibility audit two years ago. Nobody on the migration team can say whether the new one will, because the templates that produced that conformance are being rewritten from scratch, and accessibility was never scoped into the build. That is the trap in every replatform: conformance is produced by the components you are rebuilding, not stored in the content you are carrying across.
eight25 is an enterprise digital agency and certified Contentful and Contentstack partner that treats WCAG and ADA conformance as a discovery deliverable in every CMS migration, not a launch-week audit. We rebuild accessibility as a documented contract the new front end has to meet, so the replatformed site is provably conformant on the first request instead of remediated after a demand letter.
Why a Replatform Rebuilds Your Accessibility
Accessibility conformance is ultimately a property of the rendered experience rather than the CMS itself. A CMS can either support or hinder accessibility through its content model, editorial workflows, and authoring controls, but WCAG success criteria are satisfied by the HTML, CSS, JavaScript, and interaction patterns delivered to users. During a CMS migration, those presentation layers are often rebuilt, making accessibility something that must be revalidated rather than assumed to transfer.
That is the mental shift. The content of accessibility is portable. Alt text, captions, link text, and heading text are fields in your content model, and they move. What breaks is the structure and behavior wrapped around that content, and that structure is code the migration rebuilds. A migration can carry every word across faithfully and still ship an inaccessible site, because the markup that made the old site conformant no longer exists. The CMS was never where accessibility lived, which is exactly why “we migrated the content” tells you nothing about whether the new site complies.
The Legal Bar You’re Actually Being Held To
The stakes changed in the last two years, and the exposure is no longer theoretical. One standard now governs nearly everywhere that matters:
| Framework | Who it binds | Technical standard | Status as of 2026 |
|---|---|---|---|
| ADA Title II | State and local government (and their vendors) | WCAG 2.1 AA | Final rule April 2024; deadlines extended in April 2026 to April 26, 2027 (populations 50k+) and April 26, 2028 (smaller and special-district governments) |
| ADA Title III | Private “public accommodations”: retail, finance, healthcare, hospitality | No federal regulation explicitly mandates a technical standard, although courts, DOJ guidance, settlements, and industry practice overwhelmingly rely on WCAG 2.1 AA as the benchmark. | 3,117 federal web-accessibility suits in 2025 (36% of all Title III filings), up 27% year over year |
| European Accessibility Act | Any company selling covered digital services to EU consumers | EN 301 549 v3.2.1 (built on WCAG 2.1 AA) | Enforceable since June 28, 2025; penalties roughly €60k to €900k depending on member state |
| Section 508 | US federal agencies and their contractors | WCAG 2.0 AA | In force |
The pattern across all of them is WCAG 2.1 AA. WCAG 2.2 AA, published in October 2023, is where courts and standards bodies are heading and is now considered best practice. WCAG 3.0 is still a working draft. If your migration targets anything below 2.1 AA, you are building to a bar the law has already raised.
Title III deserves a specific warning, because it catches the most enterprises. No regulation names a technical standard for private companies, yet plaintiffs sue on WCAG anyway and courts accept it. There is no safe harbor and no compliance certificate that ends the risk. A replatform that quietly drops below 2.1 AA is not a deferred problem. It is a filing waiting for a screen-reader user to find it.
The Ways Accessibility Breaks at Cutover
In practice, conformance fails in a migration for reasons that never appear in a demo. The page renders, the design looks finished, and the violation stays invisible until an assistive-technology audit or a demand letter finds it.
| Failure mode | What actually happens | Where it surfaces |
|---|---|---|
| Alt text dropped in the content model | The new model has no alt-text field, or the migration script doesn’t map it, so images import with empty or filename-only alt | Screen-reader audit; a scanner flags missing alt but never meaningless alt |
| Heading and landmark order rewritten | New components emit different heading levels and landmarks (skipped levels, multiple H1s, missing main/nav) | Manual AT testing; invisible in a visual demo |
| Focus lost on client-side routing | SPA or Next.js route changes swap content without moving or announcing focus, stranding keyboard and screen-reader users | Keyboard and AT testing only; a static page scan never sees it |
| ARIA rebuilt wrong | Menus, modals, tabs, and carousels get re-implemented with missing or incorrect roles, states, and keyboard handlers | Manual audit; usually ships looking fine |
| No authoring guardrails | The new editor lets authors skip heading levels, publish images with no alt, or choose failing color combinations | Post-launch drift; found at the next audit |
| Legacy PDFs orphaned | Untagged documents are carried over as-is and stay non-conformant and in scope | Legal review; demand letters cite documents too |
None of these failures are caused by migrating content alone. Some originate in front-end implementation, while others stem from content modeling, editorial workflows, or CMS configuration. In every case, a migration introduces opportunities for accessibility regressions that must be deliberately prevented.
Where Conformance Lives in Modern Headless Architectures
The accessibility strategy for a migration is fundamentally a component strategy. This is particularly true in modern headless architectures, where reusable design-system components power multiple websites, applications, and digital experiences. Investing in accessible components means accessibility improvements propagate everywhere those components are reused, dramatically reducing regression risk over time.
This is one reason enterprise organizations increasingly adopt headless CMS platforms during replatforming projects. Because presentation is separated from content management, development teams can build and govern a shared component library that serves multiple digital properties while enforcing consistent accessibility behavior. Rather than relying on page templates embedded inside a traditional CMS, accessibility becomes part of reusable front-end components that can be tested once and deployed everywhere.
The artifact that makes this real is a component accessibility contract: a per-component definition of done that names the criteria each component must satisfy and how it gets verified.
| Component | WCAG criteria it must satisfy | Verified by |
|---|---|---|
| Nav / menu | 2.1.1 Keyboard, 2.4.3 Focus Order, 4.1.2 Name/Role/Value, 1.4.3 Contrast | Keyboard walkthrough, axe, screen reader |
| Modal / dialog | 2.4.3 Focus Order, 2.1.2 No Keyboard Trap, focus return, aria-modal | Manual keyboard, NVDA and VoiceOver |
| Form field | 3.3.2 Labels, 1.3.1 Info and Relationships, 3.3.1 Error Identification, 4.1.3 Status Messages | axe, manual error-path test |
| Route transition | 2.4.3 Focus Order, 4.1.3 Status Messages (move focus and announce) | Keyboard and screen-reader routing test |
The contract turns accessibility into a merge gate. A component isn’t done until it passes its row, with automated checks in CI and manual testing on the shared components. That is the difference between conformance designed into the system and conformance chased at the end of it.
Headless Content Modeling and the Authoring Layer
Alt text is the one part of accessibility that genuinely is portable, but only if the content model carries it. Two things have to be true: the target model needs an alt-text field on every image and asset type, and the migration mapping has to move source alt into it while flagging decorative images so they render empty alt rather than a filename.
| Asset attribute | Source location | Migration action |
|---|---|---|
| Alt text | Old CMS media field or inline img | Map to the new asset altText field; never silently drop |
| Decorative flag | Often implicit | Set an explicit “decorative” value so alt renders empty, not a filename |
| Captions and transcripts | Attached or missing | Preserve where present; flag gaps for remediation, don’t fabricate |
| Long description | Rare | Preserve where it exists |
Modern headless CMS platforms such as Contentful and Contentstack also allow teams to enforce required metadata, structured content models, validation rules, and editorial workflows that help preserve accessibility after launch. While no CMS can guarantee compliance on its own, these governance capabilities make it significantly easier to prevent common accessibility regressions before content is published.
Proving It: Scans andQ Overlays Aren’t a Compliance Strategy
Automated scanning is table stakes, not proof. Automated tools identify only a portion of accessibility issues. Industry research consistently shows that many WCAG success criteria require manual testing because they depend on context, usability, or assistive technology behavior rather than code patterns alone. A scanner finds a missing alt. It can’t judge whether the alt is meaningful, whether the reading order makes sense, or whether a keyboard user can operate a menu. The rest needs manual testing with real assistive technology.,
Accessibility overlays cannot correct structural accessibility defects in the underlying codebase, such as incorrect heading hierarchy, keyboard interaction problems, or inaccessible form semantics. In 2025, the FTC reached a $1 million settlement with an accessibility-overlay vendor over allegedly misleading accessibility claims.
That said, not every site needs a full manual audit of every template before it can launch, and pretending otherwise wastes the budget. For a small, low-risk marketing site with a tight, well-tested component set, a strict automated gate plus manual testing of the shared components is proportionate. For a public-sector site under Title II, a retailer in the litigation crosshairs, or any organization that has to hand procurement a VPAT, budget for a full manual and assistive-technology audit with a documented conformance report. The higher the exposure, the more of the proof has to be human.
Why Headless Rebuilds Often Outperform Template Porting , and 2.2 vs 2.1
Preserving what worked is often the instinct, but a CMS migration provides a rare opportunity to modernize accessibility alongside architecture. Rather than recreating inaccessible legacy templates, organizations can rebuild around reusable, accessible components and stronger editorial governance. This is especially valuable in headless implementations, where improvements made to shared components benefit every page and every future digital property that consumes them.
The standard question has a similar shape. WCAG 2.1 AA is the legal floor and the correct default target. Move to 2.2 AA when you want to build ahead of where enforcement is going, when you operate in a high-litigation sector, or when a public-sector RFP asks for it. Version 2.2 adds criteria such as focus appearance and dragging alternatives that matter for complex interfaces. Targeting 2.1 AA is defensible today; targeting 2.0 means building to a standard that no longer reflects current federal expectations for newly developed digital services. The honest answer is that 2.1 AA is what the law compels and 2.2 AA is the direction of travel, so on a multi-year replatform, building to 2.2 is usually the better investment even though 2.1 is all you are strictly required to meet.
Where Most Teams and Agencies Get This Wrong
Accessibility sits outside the migration statement of work. It’s filed under “legal’s problem” or “we’ll audit at the end,” so it’s discovered at launch instead of designed in discovery. The build team assumes the new components are fine because they look fine, and no one owns the contract between WCAG criteria and the component library.
Teams also over-trust a single automated scan. They run axe once, click through the site with a mouse, see mostly green, and call it conformant, having never tested the keyboard path or the screen-reader path that plaintiffs test first. The failure isn’t technical difficulty. It’s treating conformance as a checkbox that carries over, when it’s a property of a front end that’s being rebuilt from scratch and therefore has to be re-proven before the old site goes dark.
What eight25 Does Differently
We make accessibility a discovery deliverable, the same way we treat content modeling and integration mapping. Before build starts, we produce a component accessibility contract (the WCAG criteria each component must meet and how it’s verified), an alt-text and structured-content migration map so no image lands without its alt and no heading sequence breaks, and a conformance validation plan that defines “accessible” in testable terms and specifies the VPAT the organization will be able to hand to procurement.
We enforce it in the pipeline, not at the end. A component isn’t done until it passes its row in the contract, with automated checks in CI and manual assistive-technology testing on the shared components. Authoring guardrails go into the content model during discovery, so conformance holds after launch instead of decaying with the next campaign.
We validate before we cut over. Accessibility runs through a staging soak with keyboard and screen-reader testing on real pages, not just an axe scan, and an accessibility health check sits in the launch war room alongside performance and error monitoring. On the enterprise cutovers we’ve run, NetApp (Tridion to Contentstack, roughly 14,000 pages across 10 languages, big-bang DNS cutover on 5 June 2026, with a launch war room, first-hour rollback option, and 30-day hypercare) and Sophos (two Sitecore estates consolidated onto Contentstack, hard launch 11 December 2025 behind a 24-hour content freeze), the same discipline that protected SEO equity and uptime is where accessibility validation plugs in. [Verify: accessibility-specific steps and pass/fail thresholds used on NetApp/Sophos, including component-contract coverage, manual AT test scope, VPAT delivered, and keyboard/screen-reader pass criteria.]
Frequently Asked Questions
How do we keep our website ADA and WCAG compliant when we migrate to a new CMS?
Treat conformance as something you rebuild, not something that transfers. Your accessible content (alt text, captions, heading text) is portable if the content model carries it. What must be rebuilt is the structure and behavior: semantic markup, focus order, ARIA, and keyboard operability, all of which live in the front-end components a replatform rewrites. Define a component accessibility contract, map alt text explicitly in the migration, and validate with manual assistive-technology testing against WCAG 2.1 AA before cutover, not after.
Does accessibility transfer automatically when we migrate content to a new CMS?
No. Accessibility is a property of the rendered page, not a setting stored in the CMS. You can migrate every word of content and still ship a non-conformant site, because the templates and components that produced the old conformance are rebuilt on the new stack. The content carries over. The accessible markup around it has to be reconstructed and re-tested.
What WCAG version do we need to meet in 2026, 2.1 or 2.2?
WCAG 2.2 AA, published in October 2023, builds upon WCAG 2.1 AA by introducing additional success criteria focused on areas such as focus visibility, dragging interactions, and authentication. While most legal requirements still reference WCAG 2.1 AA, many organizations now target WCAG 2.2 AA for new digital experiences to future-proof accessibility investments.
Will an accessibility overlay make our new site compliant?
No. Overlay widgets can’t fix the structural issues that drive most WCAG violations and lawsuits, because heading order, ARIA, focus management, and form labels all live in your source code. The FTC fined a major overlay vendor $1 million in 2025 over its compliance claims, and hundreds of businesses using overlays have been sued regardless. Compliance comes from accessible source, verified by testing, not from a script layered on top.
How do I find an agency that handles accessibility in a CMS migration?
Look for a partner that puts accessibility in the migration statement of work by name, not one that files it under “legal’s problem.” Ask who owns the component accessibility contract, how alt text is mapped in the migration, and how the keyboard and screen-reader paths get validated before cutover. eight25 builds a component accessibility contract and a VPAT validation plan into the discovery phase and the launch war room, so the new site is provably conformant on day one rather than remediated after an audit.
Planning a CMS Migration and Worried About Accessibility?
If your team is replatforming and legal or procurement has started asking for a VPAT, the most useful thing you can do before cutover is map where WCAG conformance actually lives in your current site and where the new architecture will break it. At eight25, we scope accessibility as part of migration discovery, including the component-level and focus-management issues most agencies won’t surface until you’re already facing an audit.