You launched the new site, passed the accessibility audit, and checked the compliance box. Six months later, keyboard traps, low-contrast buttons, and missing alt text are back—and now every conversation starts with, “Did the redesign vendor miss something?”
Accessibility problems usually return after a redesign not because the launch work was bad, but because ongoing ownership, reusable components, and publishing workflows are unmanaged, so regressions are baked into daily changes.
This isn’t just frustrating; it’s a governance problem. If your ownership model, templates, and workflows look the same as before the redesign, you’ve essentially rebuilt an accessible version of the old system that created the issues in the first place.
In this article, we’ll treat your redesign not as a technical reset but as an X‑ray of how your team actually runs the site—and why old accessibility problems keep reappearing.
Why your “accessible at launch” redesign didn’t stay that way
On real website teams, the story often sounds like this:
- Marketing sponsors a redesign and insists accessibility is “in scope.”
- The agency or dev team builds new templates, runs an audit, and fixes the launch list.
- Leadership gets a clean report and assumes accessibility is “handled” for the next few years.
- Within months, new landing pages and blog posts start failing basic checks.
When we look back at these projects during audits, the redesign work is often solid. The issues are being reintroduced—one landing page, one promo block, one rushed content update at a time.
If you haven’t already read it, our article on related guidance on what accessibility drift looks like after launch is a helpful prerequisite: it shows how issues accumulate over time even on a stable site. This piece focuses on a narrower question: why doesn’t a big, “accessible” redesign stop that drift?
Here’s the uncomfortable answer: a redesign mostly changes how your site looks and how components are assembled. It usually does not change who owns accessibility day to day, which reusable pieces are governed, or how content actually gets published.
That gap is where regressions live.
The redesign illusion: what actually changes—and what doesn’t
Redesigns feel like fresh starts. New theme, new brand, new CMS features, new enthusiasm.
Operationally, though, far less changes than it seems.
What usually does change:
- Visual design, layout, and component library
- CMS structure and page builder options
- Initial accessibility posture at launch
What usually does not change:
- Clear accountability for accessibility after launch
- Rules for how components and templates must be used
- Workflow steps that keep rushed publishing from breaking those rules
We often see leaders assume that once patterns and components are “built accessibly,” the problem is solved. But an accessible component library without governance is like having safety rails stacked in a warehouse, not installed on the stairs.
This is where the Operational Consequence Chain kicks in:
- Redesign launches as accessible.
- Ownership is unclear and workflow debt persists.
- Components and templates lack enforced rules.
- Rushed content and design changes bypass checks.
- Known accessibility issues recur.
- Audits fail, legal and brand risk re‑emerge.
- Leadership concludes the redesign “failed” and starts planning another expensive rebuild.
The chain doesn’t start with bad intentions; it starts with assuming a one‑time project can solve an ongoing governance problem.
Root cause #1: Ownership fragmentation after launch
On most mid‑size WordPress or marketing sites, ownership is split like this:
- Marketing controls content and campaigns.
- Design or brand owns visuals and components in theory.
- Developers or IT touch templates and plugins.
- An external agency still has access and occasionally ships changes.
If nobody can answer “Who can say no to a risky change because of accessibility?”, regressions are inevitable.
Common ownership failure modes:
- Accessibility is treated as “tech” only. Marketing assumes the dev team is protecting compliance, even as they publish risky layouts in the page builder.
- No one owns the rules. You might have a design system, but there is no named owner who can update accessibility guidance when patterns change.
- Decisions are made by exception. A stakeholder needs a one‑off layout “for this campaign only,” and no one has the authority—or the process—to reconcile that exception with accessibility standards.
Operationally, this shows up as:
- New pages that look on‑brand but miss headings, labels, and keyboard focus order.
- Confusion over who should respond when someone flags an issue: “Is this dev, content, or design?”
- Long delays between discovering an issue and fixing it because it falls between roles.
Ownership fragmentation doesn’t just slow fixes; it quietly trains the team that accessibility is negotiable. That expectation will overpower any work that happened during the redesign.
Root cause #2: Reusable components and templates without clear rules
Modern sites are assembled from reusable pieces: hero banners, cards, accordions, tab sets, CTA blocks, and so on. During a good redesign, those pieces are usually built with accessibility in mind.
The problem isn’t the initial build. It’s the lack of rules for use.
We regularly see patterns like:
- A “card grid” component that works well with short headings and descriptive button text, but marketing fills it with vague copy like “Learn more,” creating ambiguous, repetitive links.
- A tabbed interface that is accessible when used once per page, but someone nests it inside another tab set and creates a keyboard nightmare.
- A hero component designed with specific color pairings, but a new campaign demands a different brand color and the contrast falls below guidelines.
The components didn’t suddenly become inaccessible. The team used them in ways the redesign never anticipated—and there were no visible guardrails to prevent it.
Governance questions to ask about components and templates:
- For each major component, do we have a short “do/don’t” usage guide that mentions accessibility, not just brand?
- Can authors actually see and follow that guidance inside the CMS, or is it buried in a design PDF?
- Who approves new variations or overrides (like new color options or layout changes), and how are accessibility checks built into that approval?
If the answer to most of these is “we don’t” or “it’s ad hoc,” your templates are quietly re‑creating the exact issues you paid to remove.
Root cause #3: Workflow debt in everyday publishing
Even with clear owners and good components, accessibility will slip if your workflows depend on memory and heroics.
Workflow debt is the hidden cost of relying on ad hoc effort instead of repeatable systems. In accessibility, workflow debt sounds like:
- “We just have to remember to run checks before we publish.”
- “We’re careful about headings—most of the time.”
- “We’ll do a big review after this campaign goes out.”
In practice, publishing looks more like this:
- Marketing has to launch a new paid campaign page by Friday.
- A designer drops in a new layout variant directly in the page builder.
- The person publishing is focused on hitting the deadline and doesn’t have time (or tools) for accessibility review.
- No one is scheduled to look at the page again unless someone complains.
Multiply that scenario across six months of campaigns and you have a site full of small, compounding regressions.
We’ve covered how routine updates can reintroduce issues in more detail in other articles; this piece is about the governance failures that let that workflow debt keep growing instead of being paid down.
A simple governance diagnostic: where regressions are being reintroduced
You don’t need deep technical skills to pinpoint where your redesigned site is slipping. You need a simple, honest diagnostic across three areas: ownership, components, and workflows.
Use these questions in a meeting with your team. Aim for clear yes/no answers, not “it depends.”
Ownership
- Single accountable owner: Is there one clearly named role accountable for website accessibility overall (even if work is distributed)?
- Decision rights: Can that owner veto or re‑shape page designs, components, or campaigns on accessibility grounds?
- Escalation path: When someone flags an issue, is it obvious where to report it and who decides what happens next?
If you have more “no” than “yes” here, regressions are likely being reintroduced whenever decisions cross team boundaries.
Components and templates
- Documented rules: For your main templates and components, do you have 1–2 pages of clear usage rules that include accessibility (not just brand)?
- CMS visibility: Are those rules visible where authors work—in the CMS, pattern library, or design system—not just in an old slide deck?
- Change control: When someone wants a new variant (new color, new behaviour, new layout), is there a defined review that includes accessibility checks?
If these answers are mostly “no,” your component library is acting as a regression delivery system.
Workflows
- Publishing checklist: Does every new page type have a short, mandatory pre‑publish checklist that includes accessibility basics (headings, alt text, focus, contrast, links)?
- Time budgeted: Are content and marketing teams actually given time in their schedules to run those checks?
- Regular review cadence: Is there a scheduled accessibility sweep (even a light one) for new content each month or quarter?
If the workflow section is mostly “no,” you’re relying on luck and goodwill instead of governance.
When you map your answers, you’ll usually see one of three patterns:
- Strong launch, weak ownership.
- Solid owners, but no component or template rules.
- Good components and owners, but high workflow debt.
That pattern is your starting point for fixing governance, not your justification for another redesign.
When to escalate from “we’ll be more careful” to a structured accessibility review
Teams often respond to regressions with promises:
- “We’ll remind everyone about headings.”
- “We’ll be more careful with color choices.”
- “We’ll run an audit before the next big launch.”
Those are good instincts, but they’re not a governance fix.
It’s time to move from informal promises to a structured accessibility review when:
- The same categories of issues keep returning. For example, color contrast or keyboard focus problems show up in every new campaign, regardless of who’s publishing.
- No one can explain how a bad page made it through. If you can’t trace which workflow step failed, you don’t have a workflow—you have improvisation.
- Accessibility conversations feel reactive and tense. Stakeholders argue about “design intent” or “brand expression” instead of referencing shared rules.
- You’re approaching a higher‑risk moment. A big launch, major campaign, or new audience (like government or education) is coming, and you don’t trust your current processes.
A structured review is not just another technical audit. The point is to map where in your Operational Consequence Chain issues are being reintroduced and then change the ownership, rules, and workflows that allow that to happen.
How Best Website’s accessibility service turns redesign fixes into durable governance
If you recognize your own site in this article, the problem isn’t that your redesign was a waste. The problem is that you never converted that redesign work into governance.
Our Website Accessibility (WCAG Compliance) work is designed to do exactly that: map your owners, components, and workflows against WCAG and turn them into a durable system instead of a one‑time clean‑up. On an engagement like this, we focus on:
- Ownership mapping: Clarifying who owns accessibility decisions across marketing, content, design, development, and external vendors.
- Component and template review: Tracing where reusable pieces are enabling regressions and defining concrete usage rules that fit how your team actually works.
- Workflow and checklist design: Reducing workflow debt by embedding lightweight checks into everyday publishing and review, rather than bolting on heavyweight audits that always slip.
If you’re ready to treat accessibility as an ongoing governance responsibility instead of a one‑off project, it’s worth spending a few minutes with our Website Accessibility (WCAG Compliance) overview to see how that structure could look on your team.
For a broader view of how accessibility governance fits with other topics like support, SEO, and performance, you can also browse our related accessibility guidance and see how these ideas connect across the rest of your website operations.
Summary: treating accessibility regressions as a governance problem, not a one‑off bug
Here’s the compressed version you can use internally: a redesign can reset your interface, but only governance can reset your behavior.
If accessibility problems keep coming back after each redesign, you should stop asking “Did our vendor miss something?” and start asking:
- Who owns accessibility decisions once the site is live?
- How are templates and components governed so they can’t be misused?
- Where in our workflows are we relying on memory instead of defined checks?
Leaving those questions unanswered has a predictable consequence: you’ll repeat the same Operational Consequence Chain—rebuild, regress, re‑audit, repeat—while legal and brand risks stay uncomfortably high.
The more constructive move is to approve a governance‑oriented accessibility review, explicitly focused on ownership, component rules, and workflow debt. To apply this decision to your own website, discuss the next step with our team.
Leaving that decision unresolved creates avoidable delay, rework, and production risk.