You can absolutely launch a WCAG-compliant site and still be right back in accessibility trouble by the next campaign cycle.
For supporting context before making that decision, related accessibility guidance explains the adjacent issue in more detail.
Choose a redesign partner by asking how they will embed accessibility into components, content workflows, and post-launch support—not just how they’ll pass WCAG at launch.
You already care about accessibility. Legal, brand, and basic respect for users made that non‑negotiable a while ago. Your real question now is: who is going to keep this thing accessible once the launch team disappears and real life kicks in?
From where we sit, that’s the decision you’re actually making when you pick a redesign partner: you’re choosing whether accessibility has an owner or whether it quietly becomes “whoever last touched the page.”
In this article, we’ll look at how different vendors treat accessibility after launch, how accessibility really decays in the wild, and the questions that expose whether a partner is thinking in projects or in ownership.
1. The real risk in your next redesign isn’t launch-day accessibility—it’s what happens six months later
Most RFPs we see ask some version of “Will the site be WCAG-compliant at launch?” That’s table stakes. The harder question is: what does month six look like?
Here’s a common pattern:
- The redesign hits its launch date with a clean accessibility audit.
- Everyone celebrates, the project team rolls off, and a smaller marketing team takes over.
- Over the next year, they add campaign landing pages, embed new third-party widgets, update navigation labels, and tweak forms.
- None of that work goes through accessibility review. The audit report sits in a folder no one opens.
- A user complaint or new internal initiative triggers another audit—and suddenly there are dozens of new barriers no one has budgeted or time to fix.
Nothing “broke.” Governance just never existed. Accessibility wasn’t embedded in components, content patterns, or support channels, so it drifted the minute day‑to‑day changes started.
You’re not buying a compliant redesign; you’re buying whether accessibility has an owner after launch.
If you take away one decision rule, let it be this: a good partner will show you exactly how accessibility survives your normal editing, publishing, and update habits. If they can’t describe that in concrete terms, you’re looking at launch‑day compliance and long‑term decay.
2. Two types of redesign partners: launch-checklist vendors vs. governance-minded teams
We see two recognizable patterns in redesign vendors.
Launch-checklist vendors
These teams talk confidently about passing WCAG, but everything is organized around launch:
- Pre-launch: They add accessibility as a QA line item: “We’ll run an audit before go‑live.”
- During build: Accessibility tasks are tickets in the backlog, often late in the process, often owned by a single specialist.
- At launch: They deliver a report, maybe a short training, and call it done.
- After launch: They might offer a “support retainer,” but it’s usually framed as bug fixing, not ongoing accessibility governance.
Their language is project‑oriented: checklist, sign‑off, phase, scope, out‑of‑scope. Accessibility is something to pass, not something to steward.
Governance-minded teams
Governance‑minded partners behave differently from the first conversation:
- Pre-launch: They ask who will actually own content and components after launch, not just who signs the SOW.
- During build: They design accessible defaults into components and templates so your editors have to work hard to break things.
- At launch: They focus on handoff, documentation, and clear decision rights, not just clearing the final audit.
- After launch: They offer an explicit support lane for accessibility questions and improvements, not just a generic ticket queue.
Their language is ownership‑oriented: patterns, roles, review cadence, guardrails, backlog, design system, support lane. Accessibility is treated as an ongoing product responsibility.
When you interview vendors, listen carefully for which world they’re operating in. One will give you a clean launch and a slow slide back into risk. The other will make your website harder to accidentally break.
3. How accessibility actually decays after launch (and why it’s a governance problem, not a bad-audit problem)
Accessibility rarely collapses because someone “stopped caring.” It decays through normal, well‑intentioned work that’s happening without guardrails.
We often see some version of this scenario on serious mid‑market sites:
- A redesign launches with strong accessibility work: headings structured, buttons logical, forms labeled, colors in range.
- The post‑launch content team gets minimal training and a dense audit PDF they don’t have time to decode.
- Over the next few weeks:
- A campaign manager copies an old landing page and swaps images without adding alt text.
- A marketer pastes a third‑party script for a chatbot that isn’t keyboard accessible.
- Someone introduces a new CTA style in the WYSIWYG editor with low contrast, because it “pops more.”
- The navigation is tweaked to highlight a new product line, but focus order is broken on mobile.
- No one realizes anything is wrong because there’s no review cadence, no clear owner, and no safe way to ask for help.
When a user complaint or internal audit finally surfaces the issues, leadership often blames the last audit or the original project. In reality, the problem was upstream: accessibility was never wired into:
- Content workflows (how pages and campaigns are created)
- Design‑system governance (how components are added or changed)
- Support lanes (where questions and regressions go)
That’s why another audit alone won’t save you. Without governance, every audit is just a snapshot of how fast things are drifting.
If you haven’t read it yet, the piece on what a design team should commit to before accessibility becomes a launch-blocking risk is a good prerequisite; this article assumes those pre‑launch basics and moves into how you choose a partner who won’t let everything unravel later.
4. A decision checklist: questions that expose whether a vendor will protect accessibility after launch
Use these questions directly in vendor interviews. The goal is not to catch anyone out; it’s to surface how they think about ownership.
1) “Who owns accessibility after launch in your model?”
- Strong answer: They describe a shared ownership model: business owns priorities, the internal web or marketing team owns day‑to‑day decisions, and the partner provides patterns, reviews, and an escalation lane. They can explain who approves changes that affect accessibility.
- Weak answer: “We’ll make sure everything is compliant when we hand it over.” No mention of ongoing decision rights.
2) “How do you embed accessibility into our CMS so editors don’t have to be experts?”
- Strong answer: They talk about structured content types, locked‑down components, sensible defaults, and inline guidance. They might mention things like required alt text fields, heading level constraints, or form templates with validation baked in.
- Weak answer: “We’ll train your team on best practices.” Training matters, but without CMS support, you’re relying on memory and heroics.
3) “What happens if we need a new component three months after launch?”
- Strong answer: They describe a lightweight design‑system workflow with accessibility review as a non‑negotiable step before new components hit production.
- Weak answer: “Just send a ticket and we’ll build it,” with no mention of accessibility review or documentation.
4) “How do content changes get checked for accessibility over time?”
- Strong answer: They suggest a realistic review cadence—e.g., quarterly audits of key templates, spot checks of major campaigns, or integrating basic checks into your publishing workflow.
- Weak answer: “You can hire us for periodic audits if you’re worried,” as if checks are a panic button instead of a routine.
5) “Where do accessibility questions go in your support structure?”
- Strong answer: They can point to a defined support lane for accessibility questions: named contact, SLAs, how items are triaged, and how decisions get documented.
- Weak answer: “Just send an email to support,” with no sign that accessibility is treated differently from a broken image.
6) “Show us how you’ve handled accessibility drift on other sites.”
- Strong answer: They describe patterns: what went wrong, which governance practices they introduced, and how they changed workflows, not just how they “fixed bugs.”
- Weak answer: “We haven’t really seen that,” or generic claims with no process detail.
If you walk out of a sales call without real, operational answers to these, assume you’re being sold a launch checklist, not a governance model.
5. What strong accessibility governance looks like inside your CMS and design system
Most buyers underestimate how much of accessibility is decided the day the CMS and design system are set up. Governance‑minded partners make very specific build‑time choices that either lock in good behavior or guarantee drift.
Here’s what to look for.
1) Content types that encode accessibility patterns
In a mature setup, your CMS doesn’t just give you a blank WYSIWYG and hope for the best. Instead, you see:
- Page types tied to user goals (e.g., article, product detail, lead form) with pre‑structured headings and regions.
- Required fields for alt text, form labels, and descriptive link text, not optional afterthoughts.
- Constrained layouts where only accessible components are available in certain contexts (e.g., hero banners, card grids, CTAs).
That configuration choice at build time is a governance decision. It determines whether marketing can accidentally ship a fully custom, inaccessible layout when a deadline looms.
2) Components with accessible defaults and limited overrides
Strong design systems bake accessibility into each component:
- Buttons, links, and form controls ship with correct roles and focus states.
- Color tokens and typography are curated so any allowed combination meets contrast.
- ARIA attributes are wired into patterns, not added ad‑hoc.
Crucially, editors can’t easily override the parts that matter. You might be able to change text and images, but not, say, downgrade a button to a span or remove labels.
3) Governance for new and changed components
Accessibility isn’t just about the launch set of components; it’s about how new ones are introduced:
- There’s a simple intake for requests: why a new pattern is needed, how it will be used, which pages it affects.
- Design and dev have a clear checklist for accessibility before a pattern is approved.
- Documentation explains when to use the new component and when not to.
We’ve noticed that when this design‑system governance is missing, new patterns often get shipped by a helpful developer or designer under pressure—and they bypass every accessibility safeguard you worked so hard to establish.
If you want a deeper contrast with design‑system‑specific decisions, the piece on choosing an accessible design system for your next website rebuild looks at that layer more narrowly; here we’re zoomed out on governance and vendor selection.
4) Guardrails, not just guidelines
Nice documentation is helpful. Guardrails are better.
Ask potential partners to show you how the CMS and design system make it harder—not easier—to introduce accessibility regressions. If their answer is mostly “we’ll send you a manual,” you’re back in launch‑only territory.
6. Roles, decision rights, and support: who actually owns accessibility after launch?
Even the best patterns fail if no one knows who can say “no” to a risky change. This is where a light RACI‑style model helps.
Think in terms of four roles (sometimes combined in real life):
- Business leadership – Accountable for the organization’s accessibility posture and risk appetite.
- Digital or marketing team – Responsible for day‑to‑day content and campaign decisions.
- Technical/IT or product team – Responsible for implementation quality and release processes.
- External partner – Consulted on complex questions; Informed of major changes; sometimes Responsible for specific improvements.
A governance‑minded vendor will help you answer, in plain language:
- Who can approve a new component or interaction that might affect accessibility?
- Who decides when to accept a tradeoff (e.g., a third‑party widget with partial support) and how is that documented?
- Who owns the backlog of accessibility improvements that aren’t urgent but are still important?
By contrast, launch‑checklist vendors often leave you with vague lines like “client is responsible for content” and “vendor is responsible for code,” which tell you nothing about who owns regressions that span both.
We often see friction six months post‑launch when:
- Marketing assumes IT will “just fix” accessibility bugs.
- IT assumes marketing “approved” the risky design.
- The vendor says it’s out of scope.
A strong partner will insist on making these decision rights explicit during the project, not wait for a dispute later.
If your team is wrestling specifically with who picks up accessibility bugs today, the article on who actually owns fixing accessibility bugs after launch: marketing, IT, or ongoing support? expands on this ownership tangle.
7. Applying the Buyer Maturity Path: are you buying a project, a support lane, or an ownership model?
One way to make sense of this choice is through the Buyer Maturity Path: how your thinking evolves from “we need a compliant site” to “we need a governance model that keeps accessibility intact.”
Stage 1: Project mindset – “We just need a compliant redesign.”
Here, the goal is clear but narrow: launch a site that passes an audit. You’re likely to:
- Optimize for price and timeline.
- Ask about WCAG, but not about post‑launch workflows.
- Treat support as an optional add‑on.
You’ll naturally attract launch‑checklist vendors. The risk is that you’ll be back in the same position in two years, paying for another big clean‑up.
Stage 2: Support mindset – “We need someone to fix things when they break.”
You’ve seen accessibility drift before and know it’s not a one‑and‑done job. You start asking about:
- Retainers
- SLAs
- How tickets are handled
This is better, but still reactive. You’re buying response time, not prevention. Accessibility remains a stream of bugs rather than a property of the system.
Stage 3: Ownership mindset – “We need accessibility wired into how the site is run.”
This is where governance‑minded partners shine. At this stage you:
- Ask how CMS configuration and design‑system choices prevent issues.
- Expect clear roles and decision rights.
- See value in a shared backlog of improvements, not just bug tickets.
You’re no longer buying hours; you’re buying an ownership model. Accessibility is treated like uptime or security: something the organization and its partner jointly steward.
If you recognize that you’ve been treating accessibility as a project or support problem and want to move into ownership, you’re exactly who this article is written for.
8. When to walk away: red flags in proposals and sales conversations
Sometimes the fastest way to protect your future self is to notice when a proposal is quietly promising you drift.
Watch for these patterns.
Red flag 1: Accessibility is a single bullet in a long deliverables list
If accessibility shows up as “WCAG 2.1 AA compliance” with no detail on how that’s achieved, governed, or maintained, assume it’s a box to be checked.
Red flag 2: No mention of your internal team
If a vendor can’t explain how your marketing, product, and IT teams will interact with the site post‑launch, they’re not designing for reality. Governance‑minded teams always ask who will be editing, approving, and releasing.
Red flag 3: Training as the only safeguard
“We’ll train your editors” is necessary but not sufficient. Without CMS guardrails, design‑system governance, and a review cadence, training turns into “remember that thing we learned last year.”
Red flag 4: Support described as “bug fixing only”
If the support section of the SOW mentions fixing defects but says nothing about pattern changes, content workflows, or accessibility questions, you’re buying a patch crew, not a partner.
Red flag 5: No backlog or roadmap thinking
If the proposal doesn’t mention how backlog items (like known accessibility improvements that didn’t make launch) will be tracked and prioritized, expect them to be forgotten.
When you see multiple red flags, it’s safer to walk away now than to explain, two years in, why you’re paying again to fix structural governance gaps that could have been addressed in the first project.
9. Turning this decision into action
At this point, you can probably see which side of the line your current vendors sit on. The key is to turn that insight into a concrete decision before your next contract is signed.
Here’s what should happen next:
- Decide what you’re actually buying. If you’re still in a project or support mindset, acknowledge that—and also acknowledge it almost guarantees future accessibility drift.
- Update your vendor questions. Bring the checklist from section 4 into your next conversation. Push for specific, operational answers about CMS patterns, design‑system governance, review cadence, and support lanes.
- Treat governance as a hard requirement. Visual design and price matter, but they shouldn’t outweigh whether accessibility will still be intact a year from launch.
Leaving this unresolved has a predictable consequence chain: you pick a launch‑only vendor, no one clearly owns accessibility, content and components drift, new barriers pile up, panic audits follow, and leadership loses trust in both the site and accessibility work itself.
A governance‑minded redesign partner will do something very different: they will help you encode accessible patterns into your CMS, define review and escalation lanes, and make decision rights explicit so accessibility doesn’t depend on one champion staying in their role.
If you want to see how that looks as a concrete engagement, our Web Design & Development work is built around this ownership model, not just launch‑day compliance; we design the site, the system around it, and the governance that keeps accessibility from slipping.
To apply this decision to your own website, discuss the next step with our team.
And if you’d like to explore more of the surrounding thinking on accessibility ownership, our collection of related accessibility guidance expands on topics like pre‑launch commitments, ownership debates, and when to escalate from tweaks to a full UX rethink, so you can place this decision inside a broader, connected strategy.