Choosing an accessibility owner when everyone touches the site and no one owns the risk

When accessibility keeps coming up as “a problem” on your site, the first question isn’t which tool to buy or which audit to schedule. It’s who actually owns the risk.

Accessibility ownership works when one accountable owner sets standards, review rules, and veto rights while everyone else stays free to publish inside those guardrails.

If you’re here, you probably already accept that accessibility is ongoing and non‑optional. What’s stuck is where it lives. Is it marketing, product, IT, legal, or a vendor? And how do you name an owner without turning every campaign into a committee meeting?

This article is about that decision. Not the perfect theoretical org chart, but the workable answer you can put in place this quarter.

---

1. The real problem isn’t accessibility skills – it’s that no one owns the risk

On most serious sites, lots of people can change things:

• Marketing launches landing pages and campaigns
• Designers add new components and layouts
• Product or UX ships new flows
• IT or engineering deploys templates and plugins
• Legal occasionally weighs in when there’s a complaint

Everyone touches the site. No one owns the risk.

We call this Ownership Fragmentation: multiple people can change the website, but no one clearly owns quality, accessibility, or long‑term structure.

In that environment, accessibility problems are guaranteed, even if you have smart, well‑intentioned people.

You’ve probably seen these patterns:

• An audit finds issues, everyone fixes them… then six months later the same issues are back but in different templates.
• Marketing “owns content,” but a new design system launches without accessibility review, and headings/contrast regress overnight.
• Legal flags an accessibility complaint, but nobody can say who had authority to stop the problematic asset from going live.

Those aren’t tooling failures. They’re governance failures.

Underneath them is another pattern: Workflow Debt. Accessibility happens (if it happens at all) through favors, ad‑hoc reviews, and heroic last‑minute checks instead of defined touchpoints. Every new campaign or release adds more debt.

If you’ve read our piece on what accessibility drift looks like when multiple teams touch the same site, you’ve already seen how this plays out in the work: issues don’t just appear once, they “drift” back into new layouts, components, and documents.

Naming an accessibility owner is how you start paying down that workflow debt and stop the drift. But only if you’re clear what “owning it” actually means.

---

2. Before you pick an owner, define what “owning accessibility” actually includes

Too many teams assign someone to “own accessibility” and quietly set them up to fail. They get blamed for problems but don’t have time, authority, or a budget. That’s not ownership. That’s holding the bag.

You’re choosing an accessibility owner, not the single person who will do all the work. Those are different jobs.

A real owner is responsible for governance and escalation, not every individual fix. In practice, that means they own:

1. Standards

   • Defining the accessibility bar you’re aiming for (e.g., WCAG level) in plain language for your teams.
   • Translating it into practical rules: which components are approved, how forms should work, how media must be handled.

2. Training and enablement

   • Making sure marketing, designers, and engineers know how to avoid the most common issues.
   • Pointing people at simple checklists, pre‑approved patterns, and examples.

3. Review points

   • Deciding where accessibility review is required (not every tiny change, but: new templates, new components, complex campaigns, new embed types, public PDFs).
   • Defining what “pass” looks like at each review point.

4. Tooling and checks

   • Selecting and configuring linters, automated checks, and monitoring tools.
   • Making sure someone actually looks at reports and acts on them.

5. Exception handling

   • Owning the process for “we need to launch, but this piece isn’t fully accessible yet.”
   • Documenting risks, time‑bound exceptions, and follow‑up work.

6. Vendor and partner oversight

   • Making sure agencies, CMS vendors, and embed providers meet your standards.
   • Ensuring third‑party scripts, iframes, and embeddable widgets are reviewed before they ship.

7. Reporting and escalation

   • Keeping leadership informed about risk and progress.
   • Being the named person who responds when legal, customer support, or a regulator raises concerns.

Notice what’s not on this list: “personally write every alt text” or “fix every ARIA attribute.”

The owner may be hands‑on some days, especially early on. But their primary function is to set rules, define review, and have veto rights when risk is too high.

Once you see ownership as governance rather than individual labor, it becomes easier to decide where it should live.

---

3. The Four‑Box Accessibility Ownership Map

Instead of arguing abstractly about “who cares most about accessibility,” map your current reality.

Most organizations fall into one of four ownership patterns, based on two axes:

• Internal vs external – is the main owner inside your org, or a partner?
• Strategic vs operational – do they set rules and standards, or are they focused on day‑to‑day execution?

Put those together and you get a simple Four‑Box Accessibility Ownership Map:

1. Internal + Strategic – accessibility lead inside marketing, product/UX, or IT who owns standards, decision rights, and escalation.
2. Internal + Operational – an individual contributor who spends time on testing and fixes but has limited authority.
3. External + Strategic – a partner that helps you define standards, governance, and overall program design.
4. External + Operational – an agency or vendor doing audits, remediation, and checks on a recurring basis.

Healthy accessibility programs usually combine one Internal + Strategic owner with targeted external support in the other boxes.

Risky patterns show up when:

• You only have External + Operational (an agency that audits occasionally) and no internal owner to enforce decisions between projects.
• You rely on Internal + Operational (e.g., a developer tasked with “fixing accessibility”) but they can’t say no to risky campaigns or component changes.
• You declare a committee as the owner (marketing + IT + legal) but nobody has tie‑breaking authority.

The decision in front of you is: which internal team should hold that Internal + Strategic box, and how will you support them?

Most teams realistically have three candidates:

• Marketing or digital/marketing operations
• Product/UX or design
• IT/engineering

And potentially, a hybrid with an external partner that plugs your gaps.

Let’s walk through each.

---

4. Marketing as accessibility owner: when it works and when it quietly fails

Marketing is often the default owner because they’re closest to content and campaigns. For many organizations, that’s a reasonable starting point.

When marketing ownership works

Marketing (or a digital marketing lead) is a strong accessibility owner when:

• The main source of change on your site is campaigns, blogs, and landing pages.
• Marketing already runs the CMS and publishing workflow.
• They have a real seat at the table for template changes and design direction.

Strengths:

• Close to copy, images, and media where many accessibility issues originate.
• Understands the pressure of launch dates and can design processes that fit reality.
• Can embed accessibility expectations into campaign briefs, content calendars, and vendor scopes.

Where it quietly fails

Marketing‑owned accessibility breaks down when:

1. No authority over design and components
   Marketing “owns accessibility,” but the design team controls the design system and can ship new components without accessibility review. Suddenly color contrasts regress, focus states disappear, or carousels return.

2. No access to development capacity
   Marketing can see the issues but can’t get engineering time to fix templates, forms, or core components. Accessibility tickets stay in the backlog while campaigns keep launching on brittle foundations.

3. Campaign pressure trumps standards
   Under pressure to hit a quarter’s pipeline target, marketing shortcuts review. Accessibility becomes “something we care about, except this time.”

4. Long‑tail content is invisible
   PDFs, embeds, and downloads get uploaded by sales, HR, or other teams without marketing oversight. As we described in our post on PDFs, embeds, and downloads bypassing review, this creates a second, unmanaged stream of risk.

Governance rules if marketing is the owner

If you decide marketing is your accessibility owner, make the role real by giving them:

• Veto rights on launches that introduce new templates, layouts, or embed types.
• Approval rights on content workflows – they can define who can publish what without review.
• Joint sign‑off with design/UX on the design system and any new components that affect accessibility.
• A guaranteed path into IT/engineering for fixes, with agreed SLAs.

In practice, that might look like:

• All new landing page layouts follow a small set of pre‑approved patterns, with accessibility baked in.
• Any deviation (a one‑off layout, interactive widget, or new embed type) triggers a quick review that marketing coordinates.
  Our piece on what to review when new landing pages introduce accessibility risk breaks down what that review should actually catch.
• Marketing can stop or adjust a launch if a page fails a basic accessibility check and no one can fix it in time.

Marketing can own accessibility successfully, but only if they own rules and veto, not just “messaging about accessibility.”

---

5. Product/UX or design as owner: strongest on patterns, weakest on long‑tail content

Product, UX, or design teams are often the natural home for accessibility in product‑led organizations. They own design systems and care deeply about user experience.

When product/UX ownership works

This model shines when:

• Most risk lives in complex flows: applications, dashboards, sign‑up funnels, account portals.
• You have a mature design system and component library used across the site.
• Product or UX already owns design tokens, components, and interaction patterns.

Strengths:

• Excellent at building accessible‑by‑default patterns: forms, navigation, modals, alerts.
• Naturally integrates accessibility into research, prototypes, and specs.
• Can gate new components on usability and accessibility before they ever reach engineering.

Where it falls down

1. Long‑tail content gets ignored
   PDFs, marketing campaigns, support articles, partner microsites. These often sit outside product/UX workflows. They become exactly the kind of unmanaged assets that create risk.

2. Limited visibility into publishing
   Product/design can control patterns, but not necessarily how content authors use them. A fully accessible template can still be misused with bad headings, missing alt text, or inaccessible embeds.

3. Slow review for marketing timelines
   Marketing needs to move fast. Product/UX review cycles might be geared toward sprints and releases, not same‑week campaigns.

We’ve seen this clash most clearly on campaign pages that use “just one new layout.” As we outlined in our post on one‑off layouts and embeds, these custom pieces bypass the carefully‑built component system and reintroduce risk from scratch.

Governance rules if product/UX is the owner

If accessibility lives with product/UX or design, they need:

• Final say over patterns – no new component or layout gets shipped without their accessibility sign‑off.
• A clear interface to marketing – rules that define when marketing can use existing components freely vs when product/UX must review.
• Shared ownership agreements – for example: product/UX owns patterns and templates; marketing owns content and assets; both must agree on new embed types or layout classes.

Operationally, that might look like:

• A limited set of CMS page types that are explicitly guaranteed as accessible if used as designed.
• A simple rule: “If you want something outside these patterns, product/UX must review and approve the design and interaction.”
• A recurring pattern review cadence (monthly or quarterly) where product/UX and engineering review issue patterns and adjust the design system.

Product/UX is a strong owner for pattern‑level risk. Just make sure someone is explicitly watching content‑level risk too.

---

6. IT/engineering as owner: strong on infrastructure, risky on content and timing

IT or engineering often gets defaulted into accessibility ownership because they “own the website.” Servers, deployments, CMS configuration, security.

Sometimes this is the only place with the technical depth to understand complex issues. But it comes with predictable tradeoffs.

When IT/engineering ownership works

This model can work when:

• Most changes are template‑driven rather than one‑off campaigns.
• IT already controls the CMS, deployment pipeline, and plugin ecosystem.
• Leadership treats accessibility like security or uptime: a clear operational requirement with budget and authority.

Strengths:

• Good at system‑level fixes: templates, components, ARIA attributes, focus management, performance impacts.
• Can integrate automated checks into CI/CD and deployment.
• Understands dependencies and technical constraints of third‑party tools.

Where it goes wrong

1. Ticket queue bottlenecks
   Accessibility becomes a backlog category. Marketing files tickets; IT prioritizes against security, outages, and strategic projects. Campaign deadlines don’t wait.

2. Late review
   Accessibility checks happen at the end of a release. Problems become expensive to fix and collide with launch schedules.

3. Content is treated as “not our job”
   Engineering fixes templates and ARIA issues but sees copy, alt text, and PDFs as someone else’s responsibility. Nobody owns the last mile.

4. “Ship now, fix later” culture
   Under pressure, IT may push changes with known accessibility issues, planning to fix them “in the next sprint.”
   Those follow‑ups are often crowded out by new work.

This is a classic Operational Consequence Chain: late review → rushed, partial fixes → recurring regressions → leadership frustration → more pressure on IT → even less time for quality.

Governance rules if IT/engineering is the owner

If you anchor accessibility in IT or engineering, you’ll need to rebalance how work flows:

• Define non‑negotiable checks in the pipeline – for example, certain automated tests must pass before deploys, and severe findings must be triaged before launch.
• Agree SLAs with marketing and product – what turnaround can they expect for fixes that block campaigns or releases?
• Clarify handoffs – who writes alt text, who fixes headings, who validates forms from a UX perspective?

Also, resist the temptation to treat accessibility as just another technical ticket. Engineering can own infrastructure and tooling, but standards, training, and content workflows still need active partners in marketing and UX.

---

7. Hybrid and external partner models: when you need an accessibility safety net

For many teams, the honest answer is:

• There is no single internal team that can do all of this well and spare the capacity.

That’s where hybrid models with an external partner make sense.

A workable hybrid typically looks like this:

• Internal owner (strategic) – someone in marketing, product/UX, or IT has clear accountability for accessibility.
• External partner (operational + advisory) – a specialist team provides standards, audits, regression checks, and training.

The internal owner:

• Decides what “good enough” means for your organization.
• Owns decision rights and veto on launches.
• Integrates accessibility expectations into briefs, sprint planning, and vendor scopes.

The external partner:

• Keeps standards current and practical.
• Runs regular checks (on high‑risk templates, campaign types, PDFs/embeds, etc.).
• Provides prioritized issue lists and remediation guidance.
• Trains your teams so everyday choices get easier.

This is the role our website accessibility service is designed to play: not just auditing once, but helping an internal owner turn governance into an everyday operating rhythm. It’s also how you avoid buying “yet another audit” without changing how work actually happens.

Tradeoffs in hybrid models

The advantages:

• Access to expertise you don’t have in‑house.
• A safety net against drift and regressions.
• A neutral outside view that can cut through internal stalemates.

The tradeoffs:

• Requires someone internal to own the relationship and act on recommendations.
• Needs clear scoping so every small change doesn’t become an external request.
• Still relies on your internal workflows to implement changes.

If you go this route, be explicit: the partner does not “own accessibility.” Your internal owner still carries accountability. The partner provides leverage.

---

8. Making one role accountable without turning accessibility into a bottleneck

Once you’ve picked a home, you still have to answer the scary question:

• How do we give one person real authority without slowing everything down?

The answer is a simple principle: one owner, many contributors, clear veto.

Make this concrete with four elements.

1. Who can change what without review?

Define safe lanes:

• Content updates inside approved templates and components.
  Example: editing copy, swapping images using pre‑checked media guidelines, updating links.
• Routine CMS edits by trained authors who’ve passed a basic accessibility training.

If someone stays in a safe lane, they can move without formal review. Automated checks can still run in the background.

2. What must be reviewed, and by whom?

List the review‑required changes:

• New templates or page types
• New or significantly changed components
• New interaction patterns (e.g., modals, accordions, carousels, complex forms)
• New embed types or third‑party widgets
• Public PDFs, downloads, and resources that will be widely shared
• Major campaigns using one‑off layouts

Then specify who reviews them and on what timeline. For instance:

• Design/UX and the accessibility owner sign off on new components.
• The accessibility owner or partner runs a pre‑launch check on high‑visibility campaigns.
• IT/engineering runs automated checks in QA environments before release.

If you want a deeper breakdown of what those reviews should catch on high‑risk assets, the posts on campaign landing pages and on one‑off layouts and embeds expand the specifics.

3. Who has veto rights?

This is where most “committees” fall apart. Without a clear tie‑breaker, standards collapse under launch pressure.

Decide in plain language:

• One named role (your accessibility owner) can say, “This can’t launch as‑is; here are our options.”
• If someone wants to override, it escalates to a named executive, not an informal argument.

That doesn’t mean they block launches lightly. It means risk acceptance is intentional, not accidental.

4. How do you handle urgent exceptions?

Urgent launches will happen. Pretending otherwise just guarantees quiet, unmanaged risk.

Define a simple exception path:

• For emergencies, the owner can approve launch with documented issues and a time‑bound follow‑up.
• Those exceptions are tracked and reported, so they don’t disappear.

This is how you stop exceptions becoming the default.

---

9. A simple decision sequence: where should accessibility live right now?

Let’s turn this into a decision you can make this quarter.

Walk through these steps.

Step 1: Identify where most change originates

Ask: Where does the majority of risk‑creating change come from today?

• If it’s frequent landing pages, blogs, and campaigns → lean toward marketing.
• If it’s complex logged‑in experiences and flows → lean toward product/UX.
• If it’s template and infrastructure changes, CMS migrations, or plugin updates → lean toward IT/engineering.

You’re optimizing for where risk enters the system, not where you wish it lived.

Step 2: Map your current failure modes

Look at your last few accessibility incidents or worries:

• Did they come from PDFs and downloads uploaded without review?
  (See the PDF/embeds piece as a good prerequisite view of that risk.)
• Did they appear on new campaign layouts?
• Did they reappear in components that were supposedly “already fixed”?

If your problems look like drift, you’re seeing Ownership Fragmentation in action. Recognizing that pattern helps you choose an owner who can actually stop the drift, not just apologize for it.

Step 3: Be honest about capacity and authority

For each candidate home (marketing, product/UX, IT):

Ask three blunt questions:

1. Can this team say no to a risky launch?
   If they can’t, they’re not a real owner.

2. Can this team change the underlying system?
   Templates, components, design system, or workflows. If they can only file tickets, they’ll be stuck.

3. Does this team have at least some dedicated time and sponsorship for accessibility?
   If not, you’re assigning a title, not ownership.

If none of the teams passes all three questions, that’s your signal you need a hybrid model: name an internal owner with at least partial authority, and pair them with a partner who can provide structure and capacity.

Step 4: Choose a “good enough for now” owner

Don’t wait for a future reorg to invent a perfect home. Pick the best viable owner for the next 12–18 months, and document it.

Write something as plain as:

“For this period, the Director of Digital Marketing is the accountable owner for website accessibility. They own standards, review rules, and veto rights on high‑risk launches, and they partner with UX and Engineering for patterns and fixes.”

Then share that, along with:

• What they own (standards, review rules, veto, escalation)
• How others contribute (who reviews what, who fixes what)
• How exceptions work

Step 5: Decide whether you need outside help

Once you’ve named an owner, ask them what would make the role realistic:

• A clear set of patterns and templates guaranteed to be accessible if used properly?
• Regular checks on high‑risk areas so they’re not manually policing everything?
• Training for content authors, designers, and engineers so fewer issues show up in the first place?

That’s where a structured service like website accessibility support can operationalize your decision: standards, reviews, and cadence that your internal owner doesn’t have to invent alone.

---

10. If you still can’t see a workable owner, treat that as a risk signal

If, after walking through this, you still can’t find any role that:

• Has (or can be given) real veto rights,
• Can influence templates, components, or workflows, and
• Has even modest time carved out for accessibility,

…then the problem is bigger than accessibility.

You’re looking at a broader website governance gap. Accessibility is simply the most visible symptom, alongside SEO drift, inconsistent content, and unstable performance.

At that point, you have two practical next moves:

1. Use accessibility as the wedge issue to fix governance.
   Treat it like security or uptime. Name an owner, give them decision rights, and build simple rules and cadences around them.

2. Bring in a partner to help design the ownership model, not just run an audit.
   A good partner will help you map where risk actually comes from, design realistic review points, and support your internal owner as they stand the program up.

If you’re at that stage and want to pressure‑test your options, you can always talk through the tradeoffs with our accessibility team before you lock in an org decision.

And if you’re ready to treat accessibility as an ongoing discipline, not a recurring project, our accessibility service is built precisely to support a named internal owner with the standards, workflows, and checks they need.

To go deeper on the day‑to‑day patterns your eventual owner will need to manage, the posts collected in the accessibility topic hub are a good next step. They move from diagnosing risk (drift, PDFs, campaigns) toward the kind of operational maturity this ownership decision is meant to unlock.