Most redesign teams know they have accessibility debt. The hard part is deciding whether to treat it as a contained remediation stream—or as evidence that the entire redesign scope is too small.
If accessibility issues are scattered exceptions, you can usually fix them inside a redesign. But when problems are baked into page templates, navigation, and content workflows, your accessibility debt isn’t a task list—it’s a signal that your redesign scope is too small and you need to reshape IA, the design system, and ongoing ownership, not just patch defects.
This article is about that scoping decision. Not WCAG theory. Not generic redesign advice. The goal is to help you decide:
- How far accessibility work needs to reach (pages vs patterns vs IA vs governance)
- Who must be involved and who has decision rights
- What to change in your redesign brief so you don’t lock in another 3–5 years of accessibility risk and Workflow Debt
If your redesign leaves the same people making the same decisions with the same tools, you’ve kept most of your accessibility debt—even if the site looks new.
1. The real decision: is accessibility a task list or a scope problem?
Most redesign scopes treat accessibility like this:
“We’ll do a quick WCAG pass in QA before launch.”
That sounds reasonable. It’s also how teams end up right back where they started a year later: inaccessible components, rushed exceptions, frustrated editors, and leadership wondering why a brand-new site is already generating risk.
Before you sign a scope or RFP, you’re effectively choosing between two models:
-
Accessibility as a task list
You assume the core templates, navigation, and workflows are basically sound. Accessibility is handled via audit, fixes, and QA at the page level. -
Accessibility as a scope problem
You assume the way your site is structured, designed, and maintained is creating accessibility issues faster than you can fix them. Accessibility changes what you redesign, who owns it, and how content is shipped.
Most teams want the task-list version because it’s smaller, cheaper, and easier to schedule before a conference or product launch. But if your debt is structural, the task-list model is a governance failure: you approve a scope that cannot actually solve the risk you already see.
The rest of this article helps you:
- Recognize when a smaller, contained scope is appropriate
- Spot signals that your debt is structural
- Use a simple “Scope Ladder” to right-size your redesign
- Make the ownership and workflow calls that keep accessibility from sliding back into one-off cleanup work
If you’re also thinking through broader redesign tradeoffs, the archive on website redesign topics is a useful companion reference.
2. Recognizing accessibility debt that fits inside your current redesign scope
Sometimes accessibility really is a fixable stream inside an otherwise solid redesign. You don’t need to restructure everything; you need clear standards, a good audit, and dedicated time for remediation.
Signals your accessibility debt is mostly “contained”
If most of these sound like you, your current redesign scope may be adequate:
-
Issues are clustered in specific content types, not everywhere.
Example: Older blog posts and a few resource PDFs lack alt text or heading structure, but core product pages and navigation are mostly fine. -
The design system can already express accessible patterns.
Your buttons, forms, and navigation have accessible variants; they’re just not consistently used. -
Navigation and key interactions are keyboard- and screen reader-usable.
Focus is visible, menus expand/collapse predictably, modals can be closed without a mouse. -
Content authors can follow accessibility rules without fighting the CMS.
Editors can add alt text, headings, labels, and transcripts using existing fields; they’re not forced into inaccessible patterns. -
Recent campaigns only created isolated exceptions.
You can name the specific pages that broke things. The problems don’t describe the whole site.
In this scenario, treating accessibility as a defined workstream inside your redesign can work:
- Run an audit across representative page types
- Prioritize issues based on impact
- Add explicit remediation time to the build
- Bake accessibility checks into page-level review
If you want a more granular sense of what review should catch at this “contained” level, the post on what accessibility review should catch before campaign exceptions multiply works as a good prerequisite and detail layer.
But when issues are everywhere and tied to the way the site fundamentally works, incremental fixes inside a narrow scope won’t hold.
3. Signals your accessibility debt is structural — and your scope is too small
Structural debt means something deeper is broken: information architecture, component behaviors, publishing workflows, or all three. You’re not just collecting defects; you’re seeing the side effects of Ownership Fragmentation and accumulated Workflow Debt.
If you’re seeing patterns like these, your redesign scope is probably too small:
-
Core navigation is inherently inaccessible
- Mega-menus that can’t be used reliably with a keyboard
- Menus that disappear when focus moves, trapping or losing users
- No skip links or way to bypass repeated navigation
-
Shared templates bake in bad interactions
- A hero component that always overlays text on images in a way that fails contrast
- A modal pattern that traps focus, or doesn’t return focus to the trigger
- Carousels that can’t be paused, controlled by keyboard, or understood by screen readers
-
The component library has inaccessible defaults
- Button styles that cannot meet contrast requirements with brand colors
- Form fields missing labels or error associations at the component level
- Icon-only controls with no mechanism to provide accessible names
-
The CMS encourages inaccessible content by design
- Free-form WYSIWYG blocks instead of structured fields, so editors fake headings with bold text
- No field to provide alt text, captions, or descriptive link text
- Hard-coded HTML in content that mixes structure, style, and behavior
-
Accessibility issues appear in every new pattern, not just legacy pages
Each new landing page, modal, or microsite repeats the same problems because the underlying patterns are wrong. -
Teams cannot explain who owns accessibility decisions
- Marketing assumes dev will “handle WCAG in code”
- Dev assumes content authors will “write accessible copy”
- Legal flags risk but doesn’t have the mandate to change scope
-
Accessibility is framed as a late QA step instead of a design and IA constraint
You hear things like, “We’ll do the accessibility pass at the end,” but no one can say how patterns will be changed if those checks fail.
When these signals show up in pre-redesign audits, it’s a sign the project isn’t just about new visuals or content. If you don’t expand scope, you’re about to sign a contract that preserves most of the system that created the debt.
This is where you need a more structured way to talk about what your redesign is really changing.
4. The “Scope Ladder”: four levels of accessibility work in a redesign
Use this Scope Ladder to place your current plan and decide whether you need to climb.
Level 1: Page-level fixes (defects)
What it is
- Fixing alt text, headings, link text, basic form labeling, and color contrast on individual pages
- Running automated scanners and spot manual checks
Who’s involved
- Content editors, QA, sometimes dev for small HTML/CSS tweaks
When this level is enough
- Patterns and templates are fundamentally sound
- Issues are truly scattered exceptions
Risk if you stop here
You’ll clear visible defects for launch, but any new content using flawed patterns recreates them. This is where many “quick WCAG passes in QA” live.
Level 2: Component & template patterns
What it is
- Auditing and fixing the design system and shared templates so they produce accessible markup and interactions by default
- Updating the component library, pattern documentation, and acceptance criteria
Who’s involved
- UX/design system lead, front-end dev, product/marketing owner, QA
When this level is required
- The same issue appears across multiple pages because of shared components
- Navigation, forms, or modals are central to your UX and need systemic change
Risk if you ignore this level
You lock in inaccessible behaviors for years. Every new page uses the same flawed components, so your team is forced into manual workarounds and exceptions. Workflow Debt spikes because “shipping a page” means overriding the system every time.
Level 3: IA and interaction models
What it is
- Reconsidering site structure, navigation hierarchy, and interaction paradigms with accessibility as an explicit constraint
- Simplifying deep or mega-menu-heavy IA, rethinking step flows, and clarifying semantics across templates
Who’s involved
- Product/marketing leadership, UX, content strategy, development, sometimes legal/compliance
When this level is required
- Users can’t reach key content without complex interactions (nested menus, modals, carousels)
- Your IA forces patterns that are hard to make accessible (e.g., navigation hidden behind multiple hover states)
Risk if you ignore this level
You spend money polishing an interaction model that will always be fragile. Accessibility issues become a permanent drag on experimentation because every new variation has to fight the base IA.
Level 4: Governance and workflow (ownership)
What it is
- Defining who owns accessibility standards, how decisions are made, what review cadence exists, and how exceptions are handled
- Updating editorial guidelines, training, and change-control processes
Who’s involved
- Marketing/communications leadership, product or digital owner, dev/IT, legal/compliance, accessibility specialist
When this level is required
- You’ve had recurring issues across multiple projects or vendors
- No one can say who has veto power over inaccessible patterns
- Content changes faster than anything gets reviewed
Risk if you ignore this level
You rebuild templates and components, but launch into the same Ownership Fragmentation that created the problem. Accessibility becomes a series of escalations and fire drills instead of a routine part of publishing.
How to use the Scope Ladder in practice
Look at your current redesign plan or RFP and ask:
-
Which level is explicitly in scope?
Most proposals claim Level 1 and parts of Level 2, whether they say it that way or not. -
Which level actually matches your debt?
Based on the signals in Sections 2 and 3, decide whether your real problems live at Level 2, 3, or 4. -
What’s the minimum rung you must reach to avoid recreating the same risk?
You don’t need to solve everything, but you do need to stop pretending a Level 1 budget can fix Level 3 problems.
When the gap between “scoped level” and “actual debt level” is large, you’re not just under-budgeted. You’re setting up an Operational Consequence Chain where today’s convenient decision becomes tomorrow’s constant drag.
If you want outside help pressure-testing which rung you’re really on and how to operationalize the right level of change, that’s exactly where our website accessibility work tends to plug into redesign projects.
5. Governance decisions that change when accessibility debt is structural
Once you acknowledge that your debt lives at Level 2–4, the question stops being “What pages do we fix?” and becomes “Who owns which decisions so this stays fixed?”
Here are the specific governance calls that typically need to change.
5.1 Ownership: who is accountable for accessibility?
You need one clearly named owner for accessibility outcomes on the site. Not to fix everything personally, but to:
- Approve standards and changes that affect patterns
- Decide when an exception is acceptable, and under what conditions
- Coordinate audits and remediation cycles
In many organizations this lives with the digital product owner, head of marketing, or a central web team lead. What matters is that they actually have authority over design, dev, and content decisions—not just a ceremonial role.
When ownership is fragmented, every fix becomes a negotiation. That’s a classic Workflow Debt pattern: easy to ignore at launch, painful for every campaign that follows.
5.2 Decision rights: who can say “no” to an inaccessible pattern?
If your accessibility lead cannot veto an inaccessible mega-menu or modal pattern, you do not have real governance.
During redesign, define:
- Which roles must sign off on any new component or template that affects navigation, forms, or media
- How accessibility acceptance criteria get written into user stories or requirements
- What happens if design and accessibility requirements conflict (who decides?)
Without this, the path of least resistance will always win—usually the visually impressive but brittle pattern.
5.3 Standards: what is “good enough,” and where is it documented?
Structural debt thrives in ambiguity. Fix that by defining:
- The baseline standard (e.g., “We design to WCAG 2.1 AA and document any exception”)
- Pattern-level guidelines (how menus behave, how focus works, how forms signal errors)
- Content-level guidelines (headings, alt text, links, transcripts, document formats)
Publish these in one place editors and designers actually use—not in a forgotten PDF. When teams know the rule set, accessibility becomes a constraint, not an argument.
5.4 Review cadence: when and how is accessibility checked?
For structural debt, review must move upstream and become routine:
- Upstream checks: Design reviews and prototype testing for new components
- Pre-launch checks: Template-level and key user-journey testing
- Ongoing checks: Quarterly spot audits or pattern reviews; checks before big campaigns
This is where earlier posts like why accessibility problems return when content changes faster than review become relevant: they show what happens when cadence doesn’t match content velocity.
5.5 Exception handling: how do you approve and track deviations?
You will have edge cases. A video without captions on day one. A third-party widget you can’t fully control.
Define ahead of time:
- When an exception can be granted, by whom, and for how long
- What compensating measures you’ll provide
- How exceptions are documented and re-reviewed
Otherwise, “just this once” becomes the norm, and your shiny new design system fills up with inaccessible variants.
6. Rescoping your redesign: what to add when accessibility shapes IA and design system
Suppose you’ve decided your debt is structural. What, concretely, should change in your redesign scope?
6.1 Expand discovery to include structural accessibility audits
Ask your team or vendors to:
- Audit representative templates and components, not just pages
- Review navigation flows and IA for keyboard and screen reader usability
- Evaluate CMS configuration and content model for accessibility support
This is more than a scan-and-report exercise. It’s about identifying which patterns need replacement, not just repair.
6.2 Put accessibility constraints into IA and design briefs
When IA and design work starts, accessibility must be written in as a constraint, not added later:
- Limit depth and complexity of navigation where possible
- Prefer simpler, more robust interaction patterns over fragile ones
- Document accessibility behaviors for each component alongside visual specs
For example, if your current mega-menu cannot realistically be made accessible, the IA brief should be explicit that the new navigation pattern must reduce complexity and support keyboard and screen reader navigation by design.
6.3 Treat the design system as part of the debt, not a neutral asset
If your design system cannot express accessible patterns easily, it is part of the problem.
Scope should include:
- Updating or replacing components whose default states fail accessibility
- Documenting usage rules and anti-patterns for editors and designers
- Building accessibility checks into the design system release process
Without this, teams will keep hacking around inaccessible components at the page level, building Workflow Debt into every campaign.
6.4 Refactor core templates and high-traffic patterns first
You probably cannot fix everything in one release. Prioritize:
- Global navigation and header/footer
- Primary product or service detail pages
- Lead-generation flows and forms
- Core content types (articles, resources, documentation)
This is where many teams get stuck in abstract “we should fix everything” debates. Narrow it to the patterns that drive revenue and core journeys, and be explicit about what’s deferred.
6.5 Align content standards and training with the new system
Rebuilding templates without updating content standards gives you accessible shells filled with inaccessible content.
Add to scope:
- Updated editorial guidelines that match new templates and components
- Short, focused training for editors on how to use new fields and patterns accessibly
- Examples of good/bad implementations for common scenarios (hero banners, CTAs, media embeds)
This is also where your existing knowledge about campaign and landing-page risk is useful. Posts like what to review when new landing pages introduce accessibility risk expand on the specific checks and patterns that tend to fail under campaign pressure.
6.6 Budget time for iteration, not just one-and-done fixes
Structural changes rarely land perfectly on the first try. Scope for:
- A feedback window after launch to collect accessibility issues
- A small backlog for refinements to patterns and guidelines
- At least one follow-up audit to verify that the new system holds under real content
If you need help translating this into concrete statements of work, our website accessibility service is designed to operationalize this kind of scope: IA and pattern audits, design system changes, and governance support, not just one-off page fixes.
7. Keeping accessibility from shrinking back to a one-time project after launch
Even with a well-scoped redesign, accessibility will drift if it’s treated as a project instead of part of how the site operates.
The recurring pattern we see:
- Teams ship a redesigned site with accessibility fixes.
- Campaigns and landing pages ramp up.
- Editors move faster than review, or bypass templates to hit deadlines.
- Exceptions accumulate. New patterns appear outside the design system.
- A year later, audits show the same problems in new clothing.
That’s not a tooling failure; it’s a governance gap.
To avoid that slide, bake these operating habits into your post-launch plan.
7.1 Make accessibility part of routine publishing, not special approvals
- Include accessibility checks in content checklists for editors
- Add light-touch peer or central review for complex page types
- Use structured fields and guardrails in the CMS instead of relying on memory
If you haven’t seen it yet, the article on what accessibility review should catch before you duplicate a landing page pattern escalates this idea for pattern reuse specifically.
7.2 Align review cadence with content velocity
If marketing is shipping new assets weekly, but accessibility review is quarterly, regressions are inevitable. This mismatch is covered in more depth in the post on why accessibility problems return when content changes faster than review, which contrasts nicely with the structural-focus of this article.
Use your content calendar to define:
- Which releases require dedicated accessibility checks
- Which can rely on guarded templates and spot audits
- When to schedule broader pattern-level reviews each year
7.3 Monitor signals of returning Workflow Debt
Watch for:
- Frequent requests to bypass templates “just this once”
- Designers or editors rebuilding components ad hoc in-page
- Support tickets clustered around the same interactions (navigation, forms, modals)
These are early signs that accessibility has slipped back into discretionary effort. Address them by fixing the patterns or process, not just the one page that complained loudest.
7.4 Keep the authority graph in mind
Your redesign is one node in a bigger system of decisions about accessibility, UX, SEO, and governance. Use the broader blog archive as an authority ladder:
- Structural and governance questions → posts like this one, plus the redesign topic hub
- Pattern and campaign questions → posts on specific reviews and exceptions
- Ongoing drift questions → posts on accessibility drift and ownership
As your team matures, your conversations should move from “Did we pass this audit?” to “Is our operating model set up so audits stop finding the same types of issues?”
Bringing it back to your immediate decision
Right now, you’re probably looking at a proposed redesign scope and a deadline, wondering whether to push for more accessibility work or accept the quick QA pass.
Use this as your internal rule of thumb:
- If problems are isolated and your design system can already express accessible patterns, keep accessibility inside the existing scope as a well-defined workstream.
- If navigation, templates, and workflows are generating issues everywhere, your debt is structural. Expand scope to at least the level of the real problem—patterns, IA, and governance—or accept that you’re signing up for years of Workflow Debt.
If you need a partner to help diagnose where your debt really lives, shape the Scope Ladder for your organization, or stand with you in scoping conversations, you can talk through the tradeoffs with our accessibility team. And if internal debate is already heating up around your redesign, it may also help to get in touch and pressure-test the plan before launch.
For more context on how accessibility fits into broader redesign choices, the archive of website redesign articles is the next logical step in the authority ladder from this piece: it connects the scope and governance decisions you’re making now to the long-term stability and usefulness of the site you’re about to rebuild.