How to decide when website accessibility needs an ongoing ownership model

Accessibility questions rarely arrive labeled correctly.

Someone flags issues after an audit, a redesign, or a big campaign push. Leadership says, “Fix this.” And you’re left deciding: is this another finite project, a sign the redesign scope is wrong, or proof that you need an ongoing accessibility ownership model?

If fixing accessibility means chasing the same problems after every campaign, redesign, or content push, you don’t have an audit problem — you have an ownership problem, and you need an ongoing accessibility model with clear standards, decision rights, and review cadence.

This article is about that decision, not about WCAG basics.

We’ll use a simple three-lane model:

1. Bounded project – a finite remediation job.
2. Redesign scope problem – the structure of the site is the blocker.
3. Ongoing ownership gap – you need a repeatable operating model.

The goal is to help you put your current situation in the right lane and choose an action that actually sticks.

---

1. The real decision: project, redesign scope, or ongoing ownership?

Most leaders don’t struggle to care about accessibility. They struggle to understand what kind of problem they’re looking at.

Common pattern:

• An audit lands with a long spreadsheet of issues.
• The redesign team promises to “bake in” accessibility.
• Marketing keeps shipping campaigns on tight timelines.
• Six months later, the same categories of issues are back in the QA notes.

From the outside, this looks like you need:

• a better audit,
• a stricter QA checklist, or
• a tougher design agency.

In reality, you probably have an ownership problem:

• Multiple teams can change the site.
• Nobody clearly owns accessibility standards across those changes.
• There’s no default review step before work goes live.

We’ve talked before about why accessibility work usually fails without ongoing ownership and how it turns into expensive rework; that post is the conceptual prerequisite. Here, we’re sharpening that idea into a decision tool: is your next move another fix, a scope change, or a new operating model?

Use this rule as you read:

If the same accessibility issue shows up three times in different projects, the fix belongs in governance, not tickets.

The rest of the article will help you decide whether you’re already at that point.

---

2. Recognizing when accessibility is a bounded project (and when it isn’t)

Sometimes accessibility really is a project. That’s good news: you can fund it, finish it, and move on.

When accessibility fits in a finite remediation project

You probably have a bounded project if most of these are true:

• Stable templates. Your site runs on a limited set of page types (e.g., product page, blog post, generic landing page) and you’re not planning major structural changes soon.
• Clustered issues. The audit shows issues concentrated in a few templates or components (e.g., your primary CTA button, one hero component, a legacy form).
• Few publishers. A small group publishes content, and they already follow reasonably consistent patterns.
• Clean release notes. Recent releases don’t show the same accessibility bugs being logged over and over.
• No major brand or IA shift coming. You are not in the middle of restructuring navigation, content hierarchy, or the design system.

In this lane, a remediation project looks like:

• Updating key components and templates.
• Fixing obvious content-level issues (missing alt text, heading structure).
• Adding a light checklist for future content.
• Training the main publishing team.

If your workflows are already stable, a focused remediation can hold for a while.

Early signals that “project” is the wrong mental model

Signs you’re trying to cram an ongoing problem into a one-off project:

• Release déjà vu. QA keeps logging the same type of accessibility bug in different releases (e.g., color contrast, focus states, form labels).
• Campaign whack-a-mole. Every new campaign or microsite spawns similar accessibility issues.
• Publishing churn. Many people can add or edit content, but none of them are trained on accessibility.
• Tool-only thinking. The plan is “run an automated scan every quarter” with no change to how content or features are created.

When you see these, a remediation project alone won’t fix the root cause. You’re probably straddling the line between too-small project and wrong redesign scope, or you’ve already crossed into ownership gap territory.

---

3. When accessibility is telling you your redesign scope is wrong

The middle lane is subtle: accessibility problems that reveal your redesign scope is mis-framed.

This is what happens when the site’s structure itself limits what’s accessible:

• Navigation patterns that can’t be made keyboard-friendly without a rebuild.
• A design system that bakes in insufficient contrast or tiny tap targets.
• Form flows that can’t surface proper labels and error messages without rethinking the interaction model.

Teams in this situation often try to:

• bolt accessibility fixes onto broken IA,
• backport accessible behaviors into an inflexible front-end, or
• rewrite content endlessly to compensate for structural issues.

That’s usually wasted energy. If accessibility issues are symptoms of deeper design or IA debt, the right move is to widen your redesign scope, not launch another isolated clean-up.

If you’re already thinking about navigation, templates, or design system changes, use the website-redesign hub as a way to see how accessibility fits into broader decisions: website redesign articles.

A companion article in that hub walks through when accessibility debt means your redesign scope is too small. You don’t need to reread that argument here, but the gist matters: don’t pretend structural problems are ticket-level issues.

Your job, as the owner of a serious revenue-supporting site, is to recognize when the site’s foundation is the limitation.

Once you’ve ruled out “just a project” and “we need a broader redesign,” whatever is left is usually an ongoing ownership problem.

---

4. Signals you actually have an ongoing ownership problem

Let’s make this concrete. Here are the Ownership Signals we see most often.

If several of these feel familiar, you’re in the ownership lane, not the project lane.

1. Repeated audit findings

• You’ve had more than one audit or review.
• The categories of issues are the same each time, just on new pages.
• Remediation work gets done… and the next audit looks similar.

This is the clearest sign that you don’t just have an issue backlog – you have a missing ownership model.

2. Campaign exceptions everywhere

Marketing pushes high-visibility campaigns on tight timelines. In theory, they’ll “circle back” to fix accessibility issues after launch. In practice:

• Exception after exception gets logged “for later.”
• Some are never fixed.
• Others turn into emergency tickets when someone complains or legal nudges.

If you need a deeper view into how those exceptions snowball, the post on what accessibility review should catch before campaign exceptions multiply expands on this pattern: What Accessibility Review Should Catch Before Campaign Exceptions Multiply.

3. Ownership fragmentation across teams

This is where ownership fragmentation bites:

• Marketing owns content and campaigns.
• Design or an external agency owns components and visuals.
• Dev/IT owns templates, hosting, and deployments.
• Legal or compliance occasionally sends worrying emails.

Everyone touches accessibility, but no one owns the rules:

• Who decides what “accessible enough” means for a new interaction?
• Who can approve an exception, and on what basis?
• Who can say “this can’t launch yet” and actually be heard?

If you cannot name a single person or role accountable for accessibility quality, you effectively have no accessibility strategy, regardless of past audits.

4. Accessibility drift after every “clean” launch

A classic pattern:

• A redesign ships with clean, tested templates.
• Six to twelve months later, audits show inconsistent headings, unlabeled buttons, new components with no keyboard support, and confusing error states.

Nothing formally changed in the design system. What changed was how people actually work.

If you want to see that arc in more detail, the article on what accessibility drift looks like after launch contrasts the initial state with what happens once normal publishing resumes: What Accessibility Drift Looks Like After Launch.

5. Legal or compliance pressure without a clear plan

You start getting:

• internal risk memos,
• questions from legal about specific journeys,
• or complaints from users and advocates.

Leadership wants reassurance that accessibility is “handled,” but all you really have is:

• a recent audit report,
• a partial remediation project,
• and no ongoing model to keep quality within a predictable range.

This is where workflow debt builds up: accessibility only gets serious attention when something hurts, and every response is an emergency.

If two or more of these signals are true, it’s time to stop asking “What should we fix next?” and start asking “Who owns the rules, and how do we work differently?”

---

5. The Accessibility Ownership Model: roles, rules, cadence, exceptions

So what does an ongoing accessibility ownership model actually look like in practice?

Think in four parts: roles, rules, cadence, exceptions.

1. Roles: who owns what

You don’t need a big committee. You need clarity.

Typical split:

• Accessibility product owner. One person (often in marketing ops, digital product, or UX) accountable for accessibility decisions and standards across the site.
• Design & UX. Own accessible components and design patterns.
• Engineering / IT. Own implementation quality and technical debt remediation.
• Content & marketing. Own content-level accessibility (headings, alt text, link text, media transcripts).
• QA / testing. Own regression checks against standards for changes.

The key is that the product owner has the authority to say “not yet” on launches that break agreed standards.

2. Rules: owning standards vs. fixing issues

This is the distinction many teams miss:

• Fixing issues = closing tickets from audits and QA.
• Owning standards = defining, updating, and teaching the rules so those issues don’t keep reappearing.

Ownership looks like:

• A short, practical accessibility standard tailored to your site (what “good” looks like for forms, navigation, media, interactive widgets).
• A decision rubric for tradeoffs (for example, when a decorative animation is worth simplifying for accessibility).
• Documentation integrated into your design system, CMS help text, and content playbooks – not just a PDF on someone’s drive.

If you keep fixing the same accessibility problems in different projects, you don’t need a better checklist — you need someone who owns the rules.

3. Cadence: when review actually happens

Accessibility review can’t live only at:

• the big redesign milestone, or
• the quarterly audit.

You need default moments when accessibility is considered:

• During design: new components and key page types get an accessibility check before handoff.
• During development: PR templates or story definitions include accessibility acceptance criteria.
• Before launch: high-impact launches (product pages, sign-up flows, major campaigns) trigger a fast, scoped accessibility review.
• After launch: periodic spot checks; a lightweight audit plan aimed at validating that the model still works, not just creating more tickets.

4. Exceptions: how you bend the rules without breaking trust

Some exceptions are inevitable. The difference between drift and governance is how you handle them.

A healthy model:

• Defines who can approve an exception (usually the accessibility product owner plus one business stakeholder).
• Requires a specific justification and a time frame (“temporary during this campaign, revisit within 60 days”).
• Logs exceptions centrally so they can be revisited.

Without this, campaign exceptions quietly become the new normal, and accessibility quality erodes release by release.

The Operational Consequence Chain

Here’s how skipping this model plays out over time:

1. Visible problem. New campaign pages launch; screen-reader users struggle.
2. Short-term reaction. Marketing logs tickets and asks for another audit.
3. Underlying gap. There are no shared standards, no review step, and no owner with authority.
4. Operational impact. QA scrambles late; launches slip; teams start avoiding updates because they fear “breaking accessibility.”
5. Downstream effect. Accessibility drift worsens after each redesign, legal pressure builds, and your next redesign becomes more expensive because it has to remediate years of inconsistent decisions.

That’s the Operational Consequence Chain: one visible issue turning into long-term workflow and governance pain because ownership wasn’t addressed.

---

6. Governance during and after a redesign: preventing drift from day one

Redesigns are the easiest time to pretend you’ve solved accessibility forever.

Here’s the usual rhythm:

• Leadership funds a redesign.
• Accessibility is a stated requirement.
• The agency designs accessible components, and dev implements them.
• You launch, proud of your “accessible new site.”
• Within a year, campaign pages and microsites start to diverge.

Nothing about your publishing workflows changed, so drift creeps back in.

To prevent that, treat governance as part of the redesign scope, not a post-launch add-on.

During redesign:

• Decide who will be the accessibility product owner after launch.
• Bake accessibility standards into design system documentation and CMS field help.
• Agree on which types of work require accessibility review before publish (e.g., new page templates, top-funnel landing pages, changes to core flows).

Immediately after launch:

• Run shorter, targeted reviews on early campaigns using the new system.
• Tune standards and checklists based on what QA finds in real use.
• Make a habit of capturing new patterns (e.g., a new interactive module) into the design system once they’ve been vetted.

If you skip this, the clean state you achieved at launch starts eroding, just as described in the piece on what accessibility drift looks like after launch: What Accessibility Drift Looks Like After Launch.

Accessibility governance and website redesign aren’t separate tracks; governance is what keeps a redesign’s accessibility gains from evaporating.

---

7. Mapping your current situation into a decision path

Let’s put this into a simple, reusable decision path.

Step 1: What’s triggering the conversation?

Ask: Why are we talking about accessibility right now?

• A new audit?
• A planned redesign?
• Recurring QA findings or campaign issues?
• Legal or user complaints?

The trigger matters because it hints at the lane you’re in.

Step 2: Run the three-lane check

Use these quick questions.

Lane A – Bounded Project

• Are issues concentrated in a few templates or components?
• Is your site structurally stable for the next 12–18 months?
• Do only a handful of people publish content?

If “yes” to most, you likely have a finite remediation project. Fund it, and require that it leaves behind basic standards and training.

Lane B – Redesign Scope Problem

• Are major templates, navigation, or flows inherently hard to fix without breaking UX?
• Is a redesign already planned or clearly needed in the near term?
• Do fixes feel like expensive hacks on top of weak foundations?

If “yes” to most, you probably need to widen your redesign scope and treat accessibility as a first-class requirement across IA, design, and build. Use the website-redesign hub to see where accessibility fits among other scope decisions: website redesign articles.

Lane C – Ongoing Ownership Gap

• Have similar categories of issues shown up in more than one audit or release?
• Do campaigns and landing pages repeatedly introduce fresh violations?
• Can multiple teams change the site, but no one owns the rules or has authority to block launches?

If “yes” to these, you’re staring at an ongoing ownership problem.

Step 3: Choose your next move

• If you’re in Lane A: Scope a remediation project with a clear endpoint and specific, limited goals.
• If you’re in Lane B: Revisit your redesign brief; add accessibility explicitly into IA, components, and templates.
• If you’re in Lane C: Stop commissioning stand-alone fixes. Design an accessibility ownership model: roles, rules, cadence, and exception-handling.

If that last lane sounds like where you are, our website accessibility services exist to help teams operationalize that model rather than just ship another report: Website Accessibility (WCAG Compliance).

---

8. When to bring in outside help to run or stress-test your model

You don’t have to build this governance function from scratch.

Outside help is usually most valuable when:

1. Designing the model. You need someone who has seen multiple ownership models to:

   • define realistic roles and standards,
   • map review cadence into your actual workflows,
   • and keep the system lightweight enough that people actually use it.

2. Stress-testing workflows. You think you have a good model on paper, but you’re not sure it will hold up when:

   • marketing needs to launch a campaign in five days,
   • product wants to tweak sign-up flows,
   • or an external agency ships a new interactive module.

3. Taking on the ongoing review role. Your team is stretched, and you’d rather have a partner handle:

   • regular accessibility reviews for major launches,
   • periodic audits aimed at checking that governance is working,
   • and coaching when new edge cases appear.

The point isn’t to outsource responsibility; it’s to avoid years of workflow debt while you’re still trying to invent a model internally.

If you suspect you’re in the ongoing ownership lane, and you want to pressure-test that conclusion or map it into a concrete plan, you can bring in outside help through our accessibility services: Website Accessibility (WCAG Compliance). When you’re ready to talk through your specific constraints and team structure, get in touch so we can walk the tradeoffs together: contact page.

The real risk isn’t deciding “too early” that you need an ownership model. It’s waiting until repeated failures – audits, complaints, failed campaigns – force your hand. At that point, you’ll still need the ownership model. You’ll just be building it under more pressure, with less room to get it right the first time.