You’ve decided accessibility can’t wait for “the next big redesign,” but now you’re stuck on scope. Do you brief a few visual tweaks, clean up the component library, or bite the bullet on a full UX rethink of your key journeys?
If most of your accessibility problems cluster around a few repeatable patterns, you need a design-system-level refresh; if they show up across journeys, content types, and workflows, you’re looking at a full UX rethink, not another round of tweaks.
This isn’t a sizing exercise; it’s a decision about what kind of experience you’re running and who actually owns it.
The lens that makes this manageable: patterns vs journeys.
- If your issues live in a handful of patterns (a button style, a modal, a card layout), you’re in refresh or refactor territory.
- If your issues show up across full tasks (can’t request a quote without a mouse, can’t complete checkout on mobile, can’t use search with a screen reader), you’re in rethink territory.
Let’s walk through how to classify what you’re seeing and what each scope really commits you to.
1. The real decision: Are you fixing patterns or rethinking journeys?
Most mid-size teams under-scope accessibility work. They approve “a quick sweep” and then wonder why the same problems come back every campaign.
The hidden problem usually isn’t WCAG knowledge or audit quality. It’s this:
- You’re redesigning pixels around an experience that was never accessible to begin with.
When you treat a UX-level accessibility problem as a design refresh, you create Workflow Debt:
- The same modal breaks keyboard focus on every landing page.
- The same form layout confuses error handling across every lead-gen flow.
- The same filter pattern is impossible to use with assistive tech on every listing page.
Individually, those look like bugs. Operationally, they’re a signal that your core patterns or journeys are wrong, not just your colors.
Before you greenlight another round of fixes, answer one question:
Do our accessibility issues mostly repeat in specific patterns, or do they block entire user journeys end to end?
Everything else in this article flows from that answer.
If your team hasn’t yet agreed what “minimum viable accessibility” looks like for new work, it’s worth skimming the commitments in What a Design Team Should Commit to Before Accessibility Becomes a Launch-Blocking Risk first; this article assumes you’re ready to act and are now choosing scope.
2. Quick triage: Three accessibility problem shapes that point to different scopes
Use this to get a fast read on where you are. You don’t need to be technical; look at your tickets, QA notes, and support themes.
A. Mostly visual and copy issues (likely a design refresh)
You’re seeing things like:
- Low-contrast text on buttons or over imagery.
- Inconsistent heading hierarchy that makes pages hard to navigate, but flows are still usable.
- Vague or missing labels on a few fields or icons.
- Focus styles that exist, but are faint or inconsistent.
Pattern: The experience basically works, but it’s harder than it needs to be for some users. Problems are annoyances, not hard stops.
B. Broken or inconsistent components and templates (likely a component refactor)
You’re seeing things like:
- The same slide-out navigation trapping keyboard focus across many pages.
- A standard “request a quote” form layout that fails screen reader checks wherever it appears.
- Accordions, tabs, filters, and modals that behave differently on each page.
Pattern: Issues cluster around repeatable components. Every time those components are reused, QA finds the same problems.
C. Inaccessible journeys and flows (likely a full UX rethink)
You’re seeing things like:
- Users can’t complete checkout, a quote request, or account signup with just a keyboard.
- Mobile and desktop flows behave so differently that one platform is effectively unusable.
- Content hierarchy is so tangled that even “fixed” components can’t save the journey.
Pattern: The task itself is inaccessible, not just one pattern. Fixes in one place reveal more issues in the next step.
If you recognize a mix of these, pay attention to where the risk and revenue sit. A visually messy content page is one thing; a broken lead flow or payment path is quite another.
3. When a design refresh is enough (and what that actually covers)
A design refresh is the smallest meaningful level of accessibility work. Think: improving the skin of your existing UX, not the skeleton.
It typically includes:
- Updating color palette and typography for contrast and legibility.
- Tightening spacing and layout for readability and focus order.
- Improving microcopy for labels, errors, and instructions.
- Making focus states visible and consistent.
Preconditions for choosing “refresh” with confidence
Treat a refresh as the right scope only if:
- Information architecture is sound. Users can find key content, and navigation patterns make sense.
- Core flows work. People can complete key tasks today, even if the experience isn’t polished.
- Accessibility bugs cluster in specific visuals, not in interaction patterns or entire flows.
If those are true, a refresh is a good way to raise your floor quickly without touching every journey.
Ownership and workflow for a design refresh
Even at this level, you’re making operational choices:
- Primary owner: Design, with product/marketing as stakeholders.
- Decision rights: Design defines the accessible baseline for colors, type, spacing, and focus treatment; development implements as the default.
- Review cadence: Accessibility is checked on new templates and high-traffic pages at each release, not just annually.
Failure mode to avoid: treating a refresh as a one-off “polish pass” and then letting anyone override those decisions ad hoc.
If you haven’t already aligned your design and content teams around basic accessibility commitments, use the earlier article on design team commitments before accessibility becomes a launch-blocking risk as the baseline and bake those into your design system and content guidelines.
4. When you need a component-level accessibility refactor
A component refactor is the middle path: bigger than a visual refresh, smaller than a full UX rethink.
You’re not changing what the site does; you’re changing how your building blocks behave so you stop re-introducing the same problems.
Signals you’re in refactor territory
Look for patterns like:
- QA notes piling up about the same modal, accordion, tab, or filter pattern.
- Designers quietly avoiding certain components because “they’re a pain to make accessible.”
- Support tickets that keep citing “can’t submit the form” or “can’t open the menu,” even after copy and contrast fixes.
What’s happening here is classic Workflow Debt: you’ve allowed broken or half-accessible components to stay in circulation. Every new page or campaign that uses them drags the same issues forward.
What a scoped component refactor includes
A component refactor usually covers:
- Auditing all reusable components and templates for accessibility behavior.
- Redesigning high-risk components (navigation, dialogs, forms, filters, tabs, accordions) to be accessible by default.
- Updating the component library (design system files, code, documentation) so the new patterns are the only supported ones.
- Setting rules for when old components are retired or replaced.
This is where teams often underestimate the work. You’re not just “fixing the nav”; you’re redefining the contract between design and development for how interaction works everywhere.
Ownership, gating, and day-to-day impact
When you choose a component refactor, you’re committing to:
- Primary owner: A cross-functional group (design + development) that owns the design system or component library.
- Decision rights: The system owner decides which components exist, how they behave, and when old ones are deprecated.
- Gates: No new templates, campaigns, or pages can ship with legacy components without an explicit exception.
- Review cadence: Scheduled reviews of component behavior, not just page-level QA.
If you skip this, you keep shipping pages that look new but are built on top of legacy patterns that can’t meet your accessibility bar.
This is also where vendor proposals start to diverge. When you’re comparing potential partners, pay attention to whether they talk only about “WCAG compliance” or whether they describe a real component-level plan. Our guidance on comparing web design proposals on accessibility governance, not just WCAG buzzwords can help you tell the difference.
5. Signals you’re actually in full UX rethink territory
A UX rethink is not about polishing or swapping components. It’s about admitting that some of your core journeys were never designed to be accessible in the first place.
Most teams resist this step because it feels big and politically hard. But if you ignore the signals, you end up spending heavily on audits and patches that never touch the real problem.
Strong triggers for a full rethink
You’re in UX rethink territory when:
- Critical flows are unusable without a mouse. Checkout, quote requests, onboarding, or account management can’t be done with keyboard and assistive tech.
- Mobile and desktop diverge so much that you effectively maintain two different, inconsistent experiences.
- Content hierarchy fights the task. Users have to jump between pages or sections to complete a simple action, and no amount of component tuning fixes the confusion.
- Accessibility issues are intertwined with business rules, forms, and messaging, not just UI patterns.
In these cases, another audit won’t help much. You don’t need a longer list of issues; you need to redesign how the journey works.
How this is different from an audit or governance push
It’s easy to blur three very different activities:
- Accessibility audit: Finds issues where you are today.
- Governance / ongoing reviews: Keeps your future changes from drifting backward.
- UX rethink: Redesigns flows so they’re accessible by design, not by patch.
We explore the governance side in How to Decide If Your Accessibility Problems Need Ongoing Governance, Not Just Another Audit. Use that when you’re debating who owns accessibility long term.
A UX rethink is different. Governance can’t save a checkout flow that’s fundamentally hostile to assistive tech.
Business risk and long-term cost
If conversion-critical flows are inaccessible, a rethink isn’t optional. It’s a revenue and risk decision.
The Operational Consequence Chain usually looks like this:
- Visible issues: Bugs and complaints around key flows (forms, checkout, navigation) pile up.
- Short-term response: Teams ship one-off fixes and workarounds; marketing writes “alternate paths” into emails and FAQs.
- Operational drag: Every new campaign or product change needs bespoke QA and manual accessibility checks, slowing releases.
- Delayed cost: Support volume grows, legal and brand risk mount, and leadership is eventually forced into a rushed, high-stakes redesign.
Rethinking UX earlier is almost always cheaper and calmer than waiting until you’re backed into a corner.
When we review multiple sites over time, we often see the same pattern: if issues cluster by journey rather than by component, the teams who treat that as a redesign problem get to a stable state much faster than those who keep patching.
6. Mapping each scope to ownership, workflow, and budget
Here’s the Refresh / Refactor / Rethink model in one place, focused on how your organization actually has to behave.
1) Design refresh
- Scope: Colors, type, spacing, contrast, basic focus states, minor content tweaks.
- Owner: Design, with content and marketing as close partners.
- Decision rights: Design defines accessible visual baselines; product/marketing can request exceptions, but design has veto power.
- Workflow impact: New templates and key pages get a visual accessibility review before launch. Publishing speed is largely unchanged.
- Budget pattern: One-time project, with small follow-up allocations.
- Risk if under-done: You look more polished, but the same broken components and flows keep causing problems.
2) Component refactor
- Scope: Navigation, modals, forms, filters, accordions, tabs, and other repeatable patterns; design system and code library updates.
- Owner: Shared design–development team that owns the component library.
- Decision rights: System owners control which components are available and how they behave; rogue patterns are not allowed into production.
- Workflow impact: Short-term slowdown as components are rebuilt and rolled out; medium-term speed-up because teams stop revisiting the same issues.
- Budget pattern: Project that may span multiple sprints or quarters, often paired with ongoing maintenance.
- Risk if under-done: You improve a few high-profile components but leave others untouched, so Ownership Fragmentation persists—no one quite knows which patterns are safe to use.
3) Full UX rethink
- Scope: End-to-end journeys for high-value tasks across devices; IA, content hierarchy, business rules, and interaction design.
- Owner: Product or a senior digital lead, with design and development as full partners; marketing, operations, and support heavily involved.
- Decision rights: A clearly identified experience owner makes tradeoffs about complexity, content, and accessibility requirements.
- Workflow impact: Release cadence changes. You move from ad hoc releases to planned phases with design validation, accessibility review, and content alignment baked into each stage.
- Budget pattern: Multi-phase project, often the core of a redesign or replatforming effort.
- Risk if under-done: You redesign the interface but not the journey logic, so teams keep working around fundamental flaws and the Workflow Debt never clears.
For many organizations, the right answer isn’t “just one.” You might:
- Start with a component refactor for your most-used patterns.
- Plan a UX rethink for a specific journey (say, request-a-quote) in the next budget cycle.
If you’re trying to map this into real timelines and investment, it can help to talk it through with a partner who does both design and development. That’s exactly how our web design and development work is structured: scopes that match the problem shape, not just the page count.
7. Designing your next accessibility push so it doesn’t become another one-off project
Once you’ve picked the right scope, the next failure mode is treating it as a one-time “fix” and then drifting back to old habits.
Here’s how to turn a project into a more sustainable rhythm.
Bake accessibility into design and delivery
Regardless of scope, put these into your normal way of working:
- Design reviews that include accessibility: Every major design review should include specific checks: keyboard behavior, focus order, labels, and error handling.
- Component-first thinking: Designers and developers work from a shared library; new work starts with known-good components, not bespoke patterns.
- Content patterns: Writers have clear guidance for headings, link text, and form labels so they don’t accidentally undo accessible structures.
Define roles, rules, and review cadence
This is where you prevent new Workflow Debt from accumulating:
- Roles: Who can change components? Who can change templates? Who approves exceptions?
- Rules: When is a new component allowed, and what proof of accessibility does it need before inclusion?
- Review cadence: Quarterly or release-based reviews of high-value templates and flows, with a small budget reserved for fixes.
If, as you map this out, you realize that your team structure can’t support ongoing design and accessibility ownership, you’re bumping into a broader question: should web design and development move into an ongoing ownership model instead of project-by-project work? We unpack that shift in How to decide when web design development needs an ongoing ownership model.
Example: the “quick sweep” that wasn’t
Picture this scenario, which we see versions of often:
- The marketing director is planning a new campaign and asks for “a quick accessibility sweep.”
- QA flags issues in the same modal form, sticky nav, and mobile filters that have shown up before.
- IT insists the platform is fine; designers say they can tweak colors and headings.
- Leadership doesn’t want a full redesign this quarter.
On paper, that looks like a refresh. In practice, it’s a component refactor (at minimum) and probably a UX rethink for your lead-gen journey.
The decision to name it that way matters. Once you call it a refactor or rethink, you can assign an owner, scope the work, and set expectations. If you keep calling it a “sweep,” it will soak up time and budget forever without fixing the root issue.
If you want help pressure-testing that kind of situation before you commit, it can be useful to walk through it with an outside team that isn’t invested in any one answer and can say, plainly, “this is actually a rethink.” Our web design and development team does that kind of scoping and tradeoff conversation at the start of every accessibility-driven engagement.
8. If you’re still unsure: A simple next-step checklist
If you’re on the fence between refresh, refactor, and rethink, use this as your next 60–90 minutes of work.
1) Look at the evidence
- Pull the last six months of accessibility tickets and QA notes. Highlight recurring components and journeys.
- Ask support for top “can’t complete” complaints related to the website.
- Review analytics or feedback around key tasks (checkout, quote, signup, account tasks).
2) Classify what you see
- Are the issues mostly visual and content-level? → Lean toward design refresh.
- Do they cluster around reusable components? → You need a component refactor.
- Do they block entire journeys or revenue-critical flows? → You’re in UX rethink territory.
3) Map to ownership
For your chosen scope, answer:
- Who has final say on accessibility decisions in this work?
- What changes in how we design, build, and launch any new page?
- How will we prevent the same class of issues from returning in six months?
If you can’t answer those, you don’t have a real plan yet—you have a task list.
4) Decide whether to bring in outside help
You may decide to:
- Handle a small design refresh internally once you’ve aligned on standards.
- Partner with a design–development team for a component refactor or UX rethink, because the changes affect your whole system.
If you’re leaning toward partner support, use our accessibility topic hub to get your internal team on the same page first, then talk with a design/development partner about how they’d scope the work.
When you’re ready to map your problem shape to a concrete scope and budget, you can talk through the tradeoffs with a team that does this every week by starting a conversation with our web design and development group. And if you already know you’re in full rethink territory and need to move quickly, you can always get in touch directly to pressure-test your plan before you commit.