Designing an Accessibility Ownership Matrix: Who Approves What When Your Website Changes

Marketing and operations leaders keep asking a version of the same question: “We fixed these accessibility issues already—why do they come back every time we ship something?” At that point, you don’t need another audit; you need a clear, shared map of who approves what when the site changes.

Implement a lightweight accessibility ownership matrix that ties specific WCAG-sensitive changes to named approvers, checklists, and release steps instead of ad-hoc ticket approvals.

This article is the operational sequel to guidance on shifting team ownership after an accessibility-focused technical review. Once you understand that an audit changes what your team owns, the next step is encoding that ownership as explicit approval rules for each kind of change—not as good intentions buried in someone’s job description.

For supporting context before making that decision, related accessibility guidance explains the adjacent issue in more detail.

Think of it like our Archive Relationship Map for your content: we deliberately assign each post a role—prerequisite, expansion, contrast, escalation—so the archive behaves as a system, not a pile of articles. Your accessibility ownership matrix does the same for website changes: it tells everyone which role they play, and at which moment, so accessibility doesn’t depend on memory or heroics.

---

Why Accessibility Keeps Breaking Every Time Your Site Changes

On most serious business sites, accessibility regressions don’t come from malice or laziness. They come from invisible gaps in approvals.

Patterns we often see during audits and support work:

• Campaign landing pages ship fast and bypass any dev or accessibility review. Alt text, labels, and focus order break again.
• Design tweaks hit shared components (buttons, form fields, navigation) without anyone accountable for contrast and keyboard behavior.
• Third-party tools are dropped in (chat, forms, event widgets) where no one feels responsible for testing screen reader and keyboard flows.
• Vendors change templates in their own sprints; your team only sees the release note after regressions hit production.

Without a visible approval map, you get this sequence:

1. A technical accessibility audit flags issues.
2. Teams fix the immediate tickets.
3. New work follows the same change workflows as before.
4. The same patterns reintroduce the same defects.

You’re treating accessibility like a backlog, not like a governance rule set.

An accessibility ownership matrix is the tool that converts “someone should remember to check that” into “this type of change cannot be approved unless these checks are done by this role, at this moment.”

If you haven’t yet grounded your team in how a technical review reshapes ownership expectations, it’s worth reading “How an Accessibility-Focused Technical Review Changes What Your Website Team Owns” as a prerequisite lens; that article explains the ownership shift this matrix is designed to operationalize. You’ll find it here: How an Accessibility-Focused Technical Review Changes What Your Website Team Owns.

---

From Audit Findings to Approval Rules: What an Accessibility Ownership Matrix Actually Is

An accessibility ownership matrix is a one-page table that ties types of website changes to who must check what, and when, before that change goes live.

It is not:

• A generic RACI chart that lists every stakeholder against every project phase.
• A long policy PDF that no one consults mid-sprint.
• A stack of audit tickets assigned to “someone in development.”

Instead, it’s a compact grid you can reference during planning and approvals.

At minimum, your matrix should have:

• Rows: Change types that have a realistic chance of affecting accessibility.
• Columns: Approval moments and roles, such as:
  • Request / brief
  • Design / UX
  • Build / implementation
  • Pre-release QA
  • Post-release monitoring
• Per-cell rules: What that role must check for that change type at that moment, linked to specific standards or checklists.

A simplified example row for “New marketing landing page” might look like this (described in words so you can sketch it):

• Row label: New campaign or resource landing page using existing templates.
• Request / brief (Marketing lead): Confirms the page can be built with existing, approved templates and components; flags any new interactive elements.
• Design (Designer or UX): If layout changes are needed, checks text size, color contrast, and focus order for any new sections.
• Build (Developer or no-code builder): Uses the approved template; ensures headings are structured (H1–H3), alt text is added for all non-decorative images, and forms use labeled inputs.
• Pre-release QA (Designated accessibility QA): Runs a short landing-page checklist plus automated tooling; blocks launch if any critical issues are found.
• Post-release (Analytics / Ops): Monitors error reporting and feedback channels for accessibility-related complaints within the first week.

What matters is that for each change type, you can answer three questions:

1. Who is allowed to approve this change at each stage?
2. What accessibility checks are they explicitly responsible for?
3. How do we know those checks happened (e.g., checklist fields, ticket statuses)?

Observable output of this step: a first-draft grid structure—rows for change types, columns for approval moments and roles, and space for per-cell rules.

---

Step 1: Map the Kinds of Website Changes That Can Break Accessibility

Most teams try to assign ownership by title (“the dev team owns accessibility”) instead of by change type. That’s why approvals feel fuzzy and regressions slip through.

Start with the rows of your matrix: the categories of change that regularly touch accessibility.

Common rows for a mid-size B2B site:

• New content pages
  • Campaign landing pages
  • Resource or blog articles
  • Product or solution pages
• Design and layout changes
  • Button styles, text styles, and color palette tweaks
  • Navigation or header/footer changes
• Template and component updates
  • Page templates in the CMS
  • Shared components like forms, cards, accordions, tabs, carousels
• Functional changes and new features
  • Forms, calculators, quote tools, wizards
  • Logged-in experiences and dashboards
• Third-party embeds and platforms
  • Chat widgets
  • Event and webinar registration
  • Embedded videos and iframes

In practice, we’ve noticed that regressions cluster around fast-moving marketing work (landing pages, promos) and vendor-driven template changes—exactly the change types that often bypass formal review.

A practical way to build this list:

1. Review your last 3–6 months of releases. Identify what actually shipped, not what your process doc says.
2. Circle items where accessibility issues reappeared. These are guaranteed matrix rows.
3. Add rows for known upcoming initiatives. New design system, new CMS, new form provider, etc.

Don’t worry about getting the rows perfect. You can merge or refine later. The goal is coverage: every realistic way someone can change the site in the next 6–12 months should fit into a row.

Observable output of this step: a list of 8–20 change-type rows that describe how your site actually evolves over a year.

---

Step 2: Define Who Owns Which Checks Before, During, and After a Change

Once you have rows, decide who does which accessibility checks and when. This is where you move from “the team owns it” to “this role cannot approve this change without doing these checks.”

Key roles you’re likely dealing with:

• Marketing or content owners
• Product or site owner
• Designers / UX
• Developers or no-code builders
• QA or dedicated accessibility reviewer
• Legal / compliance (for some industries)
• External vendors (agencies, dev shops, platform partners)

For each row, walk through the lifecycle:

1. Request / brief: Who defines the change and its constraints?
2. Design / UX: Who controls layout, components, and visual decisions?
3. Build / implementation: Who actually changes the CMS, code, or configuration?
4. Pre-release QA: Who checks the assembled page or feature before it goes live?
5. Post-release monitoring: Who is on the hook if issues are reported?

Then, for each stage, decide whether accessibility is:

• Primary responsibility (this role must check and can block), or
• Consulted or informed (this role gives input but cannot block).

Rather than a full RACI, keep it lean:

• One primary approver per stage, per change type.
• Optional secondary consults where helpful.

A realistic example: adding a new gated ebook landing page on existing templates.

• Request (Marketing manager): Commits to use existing “Lead Gen Landing Page” template; if new interaction is desired (e.g., quiz), they must involve Product or Dev before proceeding.
• Design (Designer, optional): Only involved if new imagery or layout requires deviation from templates; then they own checking contrast and typography against standards.
• Build (Marketing operations or content specialist): Owns heading hierarchy, alt text, form labels, and ensuring the correct accessible button component is used.
• Pre-release QA (Accessibility QA or designated tester): Has explicit authority to block launch if critical issues appear in their checklist.
• Post-release (Product owner or web owner): Monitors feedback; if a pattern of accessibility complaints arises, they trigger a retro and potential template update.

Notice the distinction many teams miss:

• One role might own fixing issues after they’re found.
• A different—or the same—role must own preventing regressions by controlling approvals at the earlier stages.

Your matrix is primarily about prevention ownership, not just who gets the ticket when something breaks.

Observable output of this step: for each row, you’ve assigned a clear primary approver at each stage and distinguished between who fixes issues vs. who prevents regressions.

---

Step 3: Tie Specific Accessibility Standards and Checklists to Each Approval

Named approvers mean nothing if you can’t say what they’re approving for. This is where you connect WCAG-sensitive checks directly to each matrix cell.

The goal isn’t to turn every marketer into an accessibility specialist; it’s to give each role a small, targeted checklist that fits the kind of changes they approve.

For each row-and-stage:

1. Identify the likely accessibility risks for that change type.
2. Assign 3–10 concrete checks to the responsible role.
3. Decide what tools or references they’ll use.

Continuing the “new landing page” example:

• Marketing request:

  • Checks that the business goal can be met using existing, approved templates.
  • Flags any need for video, interactive tools, or third-party forms so those can be reviewed early.

• Design (if involved):

  • Verifies minimum text sizes and line spacing.
  • Confirms color choices pass contrast for text and interactive elements.
  • Ensures focus order makes sense for keyboard users.

• Build / implementation:

  • Uses existing heading structure (one H1, logical nesting).
  • Adds descriptive alt text to meaningful images; marks decorative images correctly.
  • Uses accessible form components with labels and error messages.

• Pre-release QA:

  • Runs the page through a short manual checklist (keyboard-only navigation, focus visible, modal behavior) plus automated scanning.
  • Confirms there are no critical violations (e.g., unlabeled form fields, non-functional buttons, unreadable text against backgrounds).

Embed these checks in the tools your team already uses:

• Add fields to your ticket templates: “Accessibility impact considered? Y/N. Details: …”
• Add a small checklist section to design specs.
• Add a required checklist field to your pre-release QA tasks.

If you want more context on translating audit findings into these kinds of technical rules, the article “Who Owns Accessibility Regressions? Governance Patterns for Technical Audits That Actually Stick” expands on how governance patterns prevent backsliding once you’ve fixed issues; it pairs naturally with what you’re encoding into the matrix.

Observable output of this step: a short, role-specific checklist or rule set attached to each matrix cell where someone has primary responsibility.

---

Step 4: Embed the Matrix Into Release Workflows, Vendor Scopes, and Content Ops

A beautiful matrix in a spreadsheet that no one sees during real work is just a different kind of risk.

For the matrix to matter, you must wire it into the same tools and ceremonies where other approvals happen. If accessibility approvals aren’t visible in the same systems as other website approvals, they effectively don’t exist.

We often see this integration happen in four places:

1. Change request and ticket templates

   • Add a required field for “Change type” that must match one of your matrix rows.
   • Auto-populate the relevant approvers and accessibility checks based on that choice.
   • Example: selecting “New landing page using existing templates” auto-assigns Marketing Ops and Accessibility QA and inserts their checklists.

2. Sprint planning and release reviews

   • During sprint planning, quickly scan tickets by change type and confirm that accessibility approvers are assigned.
   • In release reviews, sample a few items from each high-risk row and ask, “Where in the ticket do we see that the accessibility checks were completed?”

3. Content and campaign calendars

   • For campaign launches, treat the matrix row as a planning constraint: “We can launch three new landing pages this month because we have capacity for three pre-release QA passes.”
   • This avoids the pattern where every campaign is urgent and accessibility is always the compromise.

4. Vendor scopes and SLAs

   • Update contracts to define which matrix rows vendors are responsible for and which checks they must perform.
   • Clarify handoffs: when a vendor changes templates, who on your side must approve accessibility before go-live?

Unclear vendor scopes are a frequent root cause of approval gaps. If your matrix doesn’t explicitly mark which vendor touches which change types—and who internally signs off on their work—you’ll keep discovering regressions you thought someone else was watching.

For teams already wrestling with whether certain regressions are just “fixable bugs” or signs of deeper template and architecture problems, the piece “When Accessibility Debt Becomes Architecture Debt: Deciding Between Patch Fixes and Template Refactors” offers an operationalization lens on when to escalate from matrix tweaks to structural changes.

Observable output of this step: updated ticket templates, workflow docs, and vendor scopes that reference your matrix rows and embed the associated approvals and checklists.

---

Hidden Failure Modes: Where Accessibility Ownership Matrices Quietly Break

Even a good matrix can decay. The common failure modes are all organizational, not technical.

1. Matrix rot

   • New change types appear (e.g., microsites, new product flows) but the matrix never gets updated.
   • Old rows remain for patterns you’ve retired, cluttering the view and eroding trust.
   • Fix: review and adjust the matrix on a regular cadence—quarterly or aligned with major roadmap updates.

2. Shadow workflows

   • Teams discover “faster paths” that avoid the official change process: direct CMS edits, emergency hotfixes, vendor-only sprints.
   • Accessibility ownership disappears along those untracked paths.
   • Fix: identify where work skips the main pipeline; either close those paths or explicitly map them into the matrix with their own owners and constraints.

3. The overloaded “accessibility person”

   • One specialist is informally treated as the gate, but they’re looped in too late or don’t have authority to stop a release.
   • The matrix lists them on every row, but in reality they’re an afterthought.
   • Fix: distribute responsibility. No single role should be the sole accessibility gate; they can provide expertise, but marketers, designers, and devs must own their portions.

4. Matrix not visible at decision time

   • It lives in a wiki or spreadsheet no one opens during planning.
   • People default to old habits because the matrix isn’t in front of them.
   • Fix: pull the matrix into the tools and moments that already drive behavior—ticket forms, sprint boards, campaign templates.

5. No feedback loop from incidents

   • When users report accessibility issues, nobody checks whether the matrix row for that change type failed or was missing.
   • The matrix never improves, so the same gap causes repeat failures.
   • Fix: treat incidents as a governance bug. For each notable issue, ask: “Which matrix row and stage should have caught this, and what change do we need?”

Observable output of this step: a short list of governance habits (review cadences, incident reviews, visibility tactics) you’ll adopt to keep the matrix alive and trustworthy.

---

When You Need Outside Help: Using a Technical Review to Stress-Test Your Matrix

Many teams can draft a basic matrix internally. The sticking point is confidence: are you actually covering the risks that matter most, or just the ones you remember from the last incident?

A Website Audit & Technical Review engagement can act like a wind-tunnel test for your matrix:

• It identifies where accessibility risk concentrates—in specific templates, components, or third-party tools.
• It shows which change types are quietly high-risk (for example, “any time we touch navigation” or “any time we embed a webinar registration widget”).
• It reveals where your current workflows already align with good practice and where they invite regressions.

In that sense, the audit findings aren’t just tickets; they are inputs into matrix design. You can trace each recurring issue type back to:

• The change type that tends to introduce it.
• The stage at which it should have been prevented.
• The role best positioned to own that prevention.

If you’re not sure whether your current audit findings justify a matrix overhaul or a deeper technical review, the article “What to review before turning accessibility audit findings into a technical website review project” offers an escalation lens: it helps you decide when simple fixes suffice and when you need broader platform-level analysis.

When we run a structured Website Audit & Technical Review, one of the explicit outputs is a clearer mapping between recurring defects and the moments in your change process where they should be caught. That mapping translates directly into stronger matrix rows and sharper approval rules.

Observable output of this step: a decision about where you need expert input—on risk identification, standards interpretation, workflow design, or all three—and a shortlist of questions you’d ask a review partner.

---

Decision Check: Are You Ready to Implement (or Overhaul) Your Accessibility Ownership Matrix?

At this point, the real decision isn’t “Should we do a matrix?” It’s whether you’ll keep treating accessibility as a stream of tickets or finally encode it as governance.

Run this quick diagnostic:

You are not ready to pause and declare success if:

• You can’t list your top 10–15 change types and name a primary approver for each stage.
• Campaign landing pages, template changes, or third-party embeds still ship without any named accessibility checks.
• Your accessibility “owner” is one overburdened person whose approvals are optional.
• Vendors can change components or templates without a clearly defined sign-off from your side.

You are ready to implement or overhaul your matrix if:

• You can sketch your rows from recent releases and near-term roadmap items.
• You’re willing to adjust ticket templates, sprint rituals, and content workflows so the matrix is visible where work happens.
• You accept that preventing regressions must be distributed across roles, not centralized in a single expert.

From a governance standpoint, the cost of delaying is straightforward:

No matrix → approvals stay informal → vendors and teams ship changes without clear checks → regressions stack up → leadership loses trust in the site and starts freezing changes or over-centralizing approvals. Growth slows because the website feels risky to touch.

The practical move is to treat the matrix as a one-page operating model: show them the table, show them how it fits into releases, and show them when they need outside review—everything else is noise.

If you’re ready to make accessibility ownership visible and durable, start by sketching your own draft matrix from the steps above, then use a focused Website Audit & Technical Review to validate where risk truly sits and which approval rules need to be stricter.

From there, a short working session with your internal stakeholders (and, if useful, with us) can translate that validated risk map into updated workflows, ticket fields, and vendor scopes. When you’re at the point where regressions are eroding trust and you need help turning audit findings into a concrete, defensible approval framework, get in touch with us and describe the change types that keep breaking—our team reads every note that comes through this contact form focused on accessibility governance questions.

Finally, as you mature beyond the initial matrix, you’ll likely want to deepen your understanding of patterns and practices across accessibility. The curated collection of related accessibility guidance in our archive serves as an expansion path, connecting this governance decision to broader content, technical, and architectural considerations without losing the operational focus of your matrix.