Most teams don’t plan to rebuild the same accessibility problems in a redesign—but it happens all the time.
Scope accessibility remediation in a redesign by fixing structural defects in templates, design systems, and CMS patterns, then governing content-level issues through post-launch workflows.
If you’ve already chosen, or are close to choosing, a redesign partner, you may have read our piece on Choosing a Redesign Partner Who Won’t Let Accessibility Slip After Launch. This article assumes that groundwork and zooms in on a narrower question: what, exactly, belongs in the redesign scope vs. ongoing support so you don’t pay for a shiny new site with the same old barriers baked in?
To answer that, you need to stop thinking in terms of “fix every issue on the audit list” and start thinking in terms of patterns you rebuild now vs. behavior you govern after launch.
We use a simple compression of that idea: fix the patterns in the redesign, govern the content after launch.
Why Redesigns Keep Rebuilding the Same Accessibility Problems
During audits and redesign planning, we often see the same pattern:
- An accessibility audit uncovers hundreds of issues.
- The findings get dropped into a spreadsheet or ticket tool.
- The redesign team promises to “address accessibility” as part of the build.
- Post-launch, support tickets and complaints show the exact same kinds of issues.
What went wrong? Not intent. Scope.
Here are the recurring failure modes:
- Accessibility scoped as QA, not architecture. Teams treat accessibility as something you check at the end of the build, instead of as a core input to templates, design system tokens, and component behaviors.
- Issue lists, not pattern fixes. Every instance of a problem—every button, every image, every heading—gets logged separately. The redesign then chases each line item instead of fixing the underlying pattern that created dozens of issues at once.
- No ownership for reusable parts. Nobody is explicitly accountable for the accessibility of navigation, forms, or CMS component libraries. So they quietly carry old defects into the new build.
- Content expectations never change. Even if the new system is more accessible, content teams are still writing, uploading, and publishing the same way they always did.
The result is classic website drift: your brand, CMS, and front-end may be “modern,” but the same structural barriers and content mistakes resurface in every new campaign.
A redesign is your single best chance to reset this. But only if you deliberately separate structural fixes, which must be rebuilt now, from content and process issues, which you can govern after launch.
The Decision You’re Actually Making: Structural Fix vs. Ongoing Governance
When you look at that big accessibility audit report next to a redesign proposal, you’re not just deciding “how much accessibility to buy.”
You’re deciding how much of your accessibility problem is:
- Structural – baked into templates, navigation, design system tokens, and CMS components.
- Governance-driven – created or prevented by how people use the system: content practices, training, approvals, and release gates.
This distinction is the core of what we call structural vs. governance scoping:
- Structural scope is everything you must rebuild now so the new platform doesn’t repeat old barriers.
- Governance scope is everything you can handle through standards, workflows, and training once the structural foundation is solid.
If you blur the line, two bad outcomes show up:
- You try to fix content-level issues with expensive rebuild work.
- You kick structural defects into “phase two” or “support”—and they never meaningfully change.
Your goal is to get to a point where every new page your team creates is accessible by default because the patterns are correct, and governance ensures people don’t work around those patterns.
Step 1: Classify Accessibility Findings Into Three Buckets
Before you argue about budget, you need a cleaner view of the problem than “300 issues.”
We recommend throwing every audit finding into three buckets:
- Design system & template defects
- CMS & component behavior issues
- Content & asset problems
1) Design system & template defects
These are problems with the reusable visual and structural patterns of your site:
- Color contrast that fails WCAG in your core palette or button styles
- Heading levels in templates that jump illogically (H1 to H4, no H2)
- Navigation that’s not logically ordered, announced, or keyboard-friendly
- Page layouts that rely on hover-only indicators or hidden controls
- Form layouts that separate labels from inputs or hide required-field indicators from assistive tech
If a defect appears anywhere that’s part of your base templates or design system, it belongs here.
If left unfixed, these issues replicate endlessly. Every new landing page built from those templates carries the same flaws.
2) CMS & component behavior issues
These are problems with how your CMS, modules, and widgets behave:
- A “card” component that doesn’t expose proper heading tags or ARIA landmarks
- A video block that doesn’t support captions or transcripts easily
- A hero component that forces text into an image instead of HTML
- Tabbed interfaces or accordions that don’t handle focus states correctly
These issues are still structural in effect, but they live in the implementation of specific components and CMS patterns, not just visual design.
Left alone, they create issues every time a publisher selects that component. You can train people all day; the component itself will keep generating inaccessible output.
3) Content & asset problems
These are issues with what’s being published, not the system itself:
- Images uploaded with missing or poor alt text
- PDFs and slide decks that aren’t tagged or readable
- Page copy that uses headings for visual styling instead of hierarchy
- Tables used for layout instead of data, or with no headers
- Videos uploaded without captions even when the platform supports them
If the underlying template/component is sound, these issues primarily come from how people create and upload content.
Left unmanaged, they become a constant stream of tickets, complaints, and small clean-up projects.
Step 2: What Must Be Fixed Inside the Redesign Scope
Once you’ve sorted findings into buckets, your redesign scope should treat Bucket 1 (design system & templates) and most of Bucket 2 (CMS & components) as non-negotiable.
Non-negotiable: structural patterns
Any issue that is:
- Present in navigation, global headers/footers, or primary page layouts
- Embedded in your color system, typography, or spacing tokens
- Part of standard components used across many templates
…belongs squarely in the redesign scope.
Concretely, that usually means:
- Navigation rebuilt for keyboard and screen reader use. That includes skip links, logical tab order, and meaningful link labels.
- Form patterns redefined in the design system. Labels, error messaging, required fields, help text, and validation feedback need to be standardized and coded accessibly.
- Color tokens updated for contrast. Don’t just darken a few buttons—fix the core palette and design tokens so every surface built from them has enough contrast.
- Template hierarchy enforced in code. Ensure headings, landmarks, and regions are structured in templates so content creators can’t break hierarchy accidentally.
When you rebuild these patterns once in the redesign, you eliminate entire categories of future issues. That’s the leverage many teams miss when they chase line items instead of systems.
High-priority: CMS and component behavior
For Bucket 2, ask: Does this component create inaccessible output even when used correctly?
If yes, it’s structural and must be fixed in the redesign:
- Update the component markup and ARIA roles.
- Add configuration options that make the accessible path the default, not the exception.
- Retire components that can’t be redeemed without complexity your team won’t maintain.
The only CMS behaviors you might postpone are:
- Very low-usage components you plan to retire soon.
- Legacy sections migrating off-platform after launch.
Everything else should be part of the build and QA plan.
Resist the “phase two” trap
We have noticed that when structural accessibility is labeled “phase two” in a redesign proposal, it often means “out of mind once launch is declared a success.”
If your agency suggests deferring navigation, forms, or core components to a later phase, treat that as a governance red flag—not just a scheduling choice.
Step 3: What Can Move to Post-Launch—If You Govern It Properly
Once structural issues are inside scope, it’s reasonable to push some Bucket 3 (content & asset) work into post-launch.
But that only works if you turn it into a governance problem, not a backlogged task list.
Content issues that can be governed
These issues are generally safe to handle through workflows and training, assuming your patterns are fixed:
- Alt text quality. If templates and components support alt text correctly, you can train teams on what good alt text looks like and enforce it through content reviews.
- Document accessibility. You can set a policy that new PDFs, decks, and long-form downloads must meet accessibility standards, with spot checks in content governance meetings.
- Heading and copy structure. With correct template hierarchy, you can publish guidelines and approve content based on whether it respects that structure.
- Media transcripts and captions. If your components support captions and transcript fields, governance can control when content goes live without them.
Governance tools you’ll need
To keep these in check post-launch, you’ll need:
- A concise content accessibility guide integrated into your broader editorial standards.
- Training for content owners so they understand how to use components, not just where to paste copy.
- Review gates in your publishing workflow—for example, an accessibility-aware reviewer signs off on major campaigns or template changes.
- Regular spot audits focused on new content, not just legacy pages.
This is where your Buyer Maturity Path shows up: moving from “we had an audit once” to “we have ongoing practices that prevent drift.”
If you want to go deeper on how accessibility governance fits into a broader ownership model, our related accessibility guidance series expands on audits, responsibility, and post-launch operations.
What should not be deferred
Some content issues are risky to delay even if they’re technically “just content”:
- Critical-path forms with inaccessible labels or instructions. If customers, patients, or applicants can’t complete essential tasks, that’s not a backlog item—that’s a revenue and trust issue.
- Key navigation labels or CTAs that are ambiguous to screen readers. If users can’t find or understand core journeys, those labels need priority attention, not a content clean-up sprint “someday.”
Treat any accessibility issue on a money-critical or trust-critical path as part of your launch criteria, even if the underlying patterns are sound.
Step 4: Converting Accessibility Scope Into Budget, Milestones, and Ownership
Once you’ve made the structural vs governance call, you need it reflected in the actual project plan, not just a conversation.
Turn buckets into scope language
For each bucket, write down:
- What’s in-scope for redesign (with examples of patterns and components)
- What’s in-scope for launch content (e.g., top 50 pages, all key journeys)
- What moves into post-launch governance (with explicit owners)
Then translate that into RFP or SOW language like:
- “Rebuild primary navigation, header, and footer patterns to meet agreed accessibility criteria, including keyboard navigation, focus management, and assistive technology announcements.”
- “Refactor global form components (contact, signup, account) to standardize labels, errors, and required fields.”
- “Update all design system tokens for color and typography to meet contrast and hierarchy requirements, and document usage.”
This is where Editorial Compression is useful: make sure stakeholders can repeat the core model in short form—fix patterns in the redesign, govern content after launch—so decisions stay consistent as details shift.
Milestones and sign-offs
Add explicit accessibility milestones, such as:
- Design system accessibility review complete before detailed dev estimates are locked.
- Template-level accessibility QA completed before content migration ramps.
- Component accessibility verification for each key module before it’s used in production content.
And update sign-off checklists so launches can’t proceed if:
- Navigation and forms fail basic keyboard and screen reader checks.
- Design tokens don’t meet contrast requirements.
- CMS components still generate inaccessible structures.
In support work, we’ve seen that when these gates are missing, accessibility concerns become last-minute “bugs” instead of criteria—expensive and politically fraught to address.
Ownership and RACI
For governance, decide in advance:
- Who owns accessibility of design system and templates (often design + front-end dev).
- Who owns accessibility of CMS configuration and components (often product or platform team).
- Who owns accessibility of content and assets (often marketing, comms, or business units).
Map those into a simple RACI so post-launch defects don’t bounce between design, dev, and content teams indefinitely.
If you’d like a complementary angle on how ownership plays out after launch—especially when defects show up in tickets—our article on “Who Owns Accessibility Defects Found After Launch” offers a useful contrast to this redesign-scope focus.
Hidden Failure Modes to Guard Against When Scoping Accessibility
Even with a solid model, there are subtle risks that creep into real projects.
1) Underestimating content volume
A marketing director sits in a redesign kickoff with an audit listing 400 issues. The agency proposes: “We’ll fix everything in templates and clean up your top 50 pages; the rest we’ll handle as a post-launch support bucket.”
On paper, that sounds reasonable. In practice, the team:
- Migrates hundreds of pages without structured content checks.
- Launches with many old PDFs, tables, and media assets intact.
- Starts receiving a steady stream of accessibility tickets from customers and internal teams.
The support bucket explodes, not because the redesign failed, but because content volume was never realistically sized for manual clean-up.
2) Ignoring third-party widgets and embeds
Calendars, chat tools, marketing widgets, and analytics overlays can all introduce accessibility problems that your redesign can’t fully control.
If an audit flags these, you need one of the following in the scope:
- Replace or reconfigure the tool.
- Put accessibility commitments into vendor contracts.
- Put blocking rules in place (e.g., “no new third-party widgets without accessibility review”).
Leaving this out of scope leads to a common failure: the core site improves, but critical flows like booking or checkout remain problematic because embedded tools were treated as someone else’s problem.
3) Trusting a one-time audit to “cover” the redesign
An audit done before the redesign is a starting point, not a guarantee.
If you simply attach the report to your RFP and expect “address these” to translate into pattern-level fixes, you will likely:
- Pay for one-off remediation during build.
- Discover that only some patterns were updated.
- Have no clear alignment between audit findings and new design system documentation.
The audit needs to be reinterpreted through your three buckets and turned into structural requirements, not just a list of defects to swat.
4) No budget for documentation or training
You can get all the patterns right and still fail if no one writes down how to use them.
If your redesign budget has no line item for:
- Updating your content and design guidelines
- Training content owners and approvers
- Creating a basic internal accessibility checklist
…then governance will rely on individual heroics. Those burn out. Patterns drift. Issues creep back.
How a Web Design & Development Partner Can Own the Structural Side
All of this is hard to orchestrate alone if you don’t live in design systems and CMS builds every day.
A strong partner doesn’t just accept your audit list; they help you reframe it into structural vs governance scope and then design the project around that split.
On the structural side, a capable team should be able to:
- Audit your existing templates, navigation, and components with an eye for pattern-level defects.
- Propose a new or updated design system that bakes in accessible color, type, and layout decisions.
- Rebuild navigation and form patterns to be accessible by default.
- Refactor CMS components so that when content owners use them correctly, the output is accessible without extra coding.
Best Website’s Web Design & Development work is structured to do exactly that: we treat templates, design systems, and CMS patterns as the foundation, not as an afterthought tacked onto QA.
Then, together with your internal team, we define what moves into governance: which content will be remediated pre-launch, what standards new content must meet, and how we’ll check that over time.
If you want more background on recognizing whether proposals you’re seeing truly handle governance, our article on comparing web design proposals by accessibility governance (not just buzzwords) is a good expansion beyond this scoping lens.
If You Get the Scope Right, Governance Gets Easier
The crux of your decision isn’t “Do we care about accessibility in this redesign?” It’s “Will we use this redesign to fix structural patterns so we can govern content sanely afterward?”
If you under-scope structural work, you know what happens next:
- The same issues reappear in every campaign.
- Ticket queues fill with repetitive accessibility bugs.
- Support and dev budgets swell with rework.
- Internal trust in the website—and in the redesign project—erodes.
If you treat structural fixes as core scope and content as a governed practice, the opposite happens:
- New pages are accessible by default because they inherit good patterns.
- Governance is about coaching and spot checks, not firefighting.
- Support contracts focus on real enhancements, not cleaning up avoidable defects.
From here, the decision is concrete:
- Classify your audit findings into the three buckets.
- Insist that design system, template, navigation, form, and key component fixes sit inside the redesign scope—not in a vague phase two.
- Define a realistic governance plan for content and assets, with owners and review gates.
If you’re staring at a complex audit and a stack of proposals and want to be sure the scope you approve will actually retire systemic issues, it’s worth talking with a team that lives in this structural vs governance split. In our Web Design & Development engagements, we walk through your findings, identify which patterns must be rebuilt, and translate that into design system changes, CMS work, and launch criteria you can put into a contract.
To apply this decision to your own website, discuss the next step with our team.