What to put in an accessibility runbook so campaigns stop reinventing the rules every quarter

Marketing is pushing a Q4 campaign live. Design wants a new hero layout, your agency has brought in a custom form pattern, legal is nervous after a complaint, and suddenly everyone is re-arguing headings, buttons, and error messages from scratch.

That pain is not an accessibility problem. It’s a governance problem.

An accessibility runbook should be a short, owner-led playbook that defines who can change what, which patterns are pre-approved, how exceptions are handled, and when accessibility is reviewed—not another checklist buried in a shared drive.

In other words: if you don’t write down how accessibility decisions are made, your campaigns will happily rewrite the rules for you every quarter.

This article is about what needs to be in that runbook, how it’s used, and how it keeps your site from drifting back into risk.

---

1. The decision in front of you: do you actually need an accessibility runbook?

If any of these feel familiar, you’re ready for a runbook:

• Every big campaign re-opens the same arguments about button styles, headings, and form layouts.
• Designers and agencies keep proposing one-off components “just for this landing page.”
• Content editors treat alt text, link text, and transcripts as optional until someone insists.
• Different teams cite different sources of truth: brand guidelines, old dev tickets, a PDF from the first audit.
• The last accessibility fixes quietly disappeared when a new template or vendor arrived.

Those are symptoms of accessibility workflow debt: repeated effort and conflict because decisions are made ad hoc instead of through a repeatable system.

You’ve likely already felt this sequence:

1. A concern or complaint surfaces.
2. You commission an audit or fix project.
3. Everyone agrees on changes… for a moment.
4. A new campaign or redesign arrives and shortcuts the new rules.
5. Six months later, the next audit flags the same categories of issues.

We’ve written before about why issues come back when editorial exceptions ignore heading and link rules; that post is essentially a prerequisite for this one. If those patterns sound familiar, pause and skim why accessibility problems return when exceptions ignore heading and link rules before you lock in your runbook.

The decision in front of you isn’t “should we care about accessibility?” — it’s “do we keep paying this workflow debt every quarter, or do we create a simple, enforceable playbook?”

If your site is revenue-supporting, has recurring campaigns, and has had at least one audit, our point of view is blunt: you need a runbook.

---

2. Accessibility runbook vs. policy vs. audit: don’t confuse the tools

A lot of teams stall here because they mix three very different artifacts:

• Policy – What the organization believes and must comply with.
• Audit – What’s broken on the site at a specific moment.
• Runbook – How people do the work tomorrow.

Policy: the promise and legal posture

Your policy might say:

• “We aim to conform to WCAG 2.1 AA.”
• “We will provide alternate channels for users who cannot access content.”
• “We will remediate critical barriers within X days.”

It’s important, but it doesn’t help a marketer decide which hero layout is acceptable under deadline.

Audit: the snapshot

An audit gives you a list of issues and recommended fixes:

• “Buttons lack visible focus outlines.”
• “Form errors are only indicated by color.”
• “Headings skip from H2 to H4 in template X.”

Useful, but it ages quickly. Six months later, new campaigns and templates may have reintroduced variants of the same problems.

We’ve talked elsewhere about what to review before turning concerns into an accessibility improvement plan. That plan decides what to fix and in what order.

Runbook: the operating manual

The runbook answers questions like:

• “Which button patterns are pre-approved?”
• “What’s our standard for alt text on campaign graphics?”
• “Who must review a new form pattern before it goes live?”
• “What checks run before a high-traffic launch?”

It should:

• Be short enough that busy teams actually use it.
• Change over time as your site, tools, and team change.
• Tie directly into real workflows (campaign launches, template changes, vendor onboarding).

Without a runbook, audits become recurring line items instead of one-time turning points. You fix the surface, but the Operational Consequence Chain is still in place: every new project quietly reintroduces risk, governance confidence erodes, and eventually legal or compliance steps in with heavier controls.

---

3. Start with ownership: who holds the runbook and who can change it

A runbook without a clear owner is just a shared document.

If you haven’t already chosen an accessibility owner, back up and make that decision first; our piece on choosing an accessibility owner when everyone touches the site and no one owns the risk walks through that choice.

For the runbook itself, use this simple model:

One owner, many contributors.

Concretely:

• Accountable owner
  One named person (often in marketing operations, digital product, or web team leadership) who:

  • Maintains the runbook.
  • Decides what changes are accepted.
  • Arbitrates conflicts between design, marketing, and IT.

• Contributors
  Roles that feed information and requests into the runbook:

  • Design/UX: patterns, components, visual standards.
  • Engineering/IT: templates, platform constraints, release cycles.
  • Content/editorial: copy patterns, workflows, training needs.
  • Legal/compliance: regulatory requirements, risk appetite.
  • Vendors/agencies: proposed patterns and workflows they’ll follow.

• Approvers for exceptions
  Often a small trio: the owner plus one design and one engineering lead for high-impact changes.

What to decide explicitly:

• Who can propose a change to the runbook.
• Who can approve a new component or content rule.
• Who can grant campaign exceptions and under what conditions.
• What happens when a team ships something outside the rules (this is where unresolved Ownership Fragmentation quickly surfaces).

If those decision rights are fuzzy, every campaign becomes a negotiation. The runbook isn’t there to add process for its own sake—it’s there to stop refighting the same battles.

---

4. The five core sections every accessibility runbook should include

You can organize it however you like, but most effective runbooks share five sections:

1. Scope and principles – What this runbook governs and the short list of rules everyone should remember.
2. Pre-approved patterns and components – The visual and interaction patterns that are safe to reuse.
3. Content rules and editorial habits – How editors, marketers, and agencies write and assemble content.
4. Review cadence and triggers – When and why accessibility is checked.
5. Exception and escalation workflow – How to say “yes, but safely” when something doesn’t fit the rules.

We’ll walk through each, then layer in tooling and update rituals.

As you read, keep a simple mental model in view:

Roles, Rules, Rhythm, and Relief.
Roles: who decides. Rules: what’s allowed. Rhythm: when it’s reviewed. Relief: how teams get help when they’re under pressure.

Your runbook should make all four explicit.

---

5. Section 1 – Scope and principles: what this runbook governs (and what it doesn’t)

Scope is where many runbooks quietly fail. If it’s too broad, no one can keep it current. Too narrow, and campaigns fall through the cracks.

Define scope clearly:

• Channels covered
  For example:

  • Corporate marketing site (all templates).
  • Campaign and PPC landing pages.
  • Blog and resource center.
  • Web forms and lead capture flows.
  • Embedded video and audio players.

• Channels explicitly out of scope (for now)
  Be clear about what this document doesn’t govern:

  • Native mobile apps.
  • Third-party portals where you can’t control markup.
  • Legacy PDFs handled by another process.

• Connections to other standards
  Reference—but don’t restate—your broader policy or legal posture. A sentence or two is enough:

  • “This runbook operationalizes our commitment to WCAG 2.1 AA on all primary web properties.”

Then add 3–5 short principles that are easy to remember and enforce, such as:

• “Don’t ship a custom button or link style that hasn’t been tested against our component rules.”
• “Never sacrifice keyboard access for animation or visual effects.”
• “Every non-decorative image ships with meaningful alt text or a documented exception.”
• “High-traffic campaigns must pass the pre-launch accessibility check before going live.”

If a busy marketer can’t skim this section in one minute and know what applies to their campaign, it’s too abstract.

---

6. Section 2 – Pre-approved patterns and components: stop redesigning buttons every quarter

This section turns design-system intent into something campaign teams can actually use.

List reusable, accessibility-tested UI patterns, such as:

• Buttons and links (primary, secondary, text links).
• Form fields (text inputs, selects, checkboxes, radios).
• Validation and error messages.
• Navigation (menus, breadcrumbs, tabs).
• Modals and dialogs.
• Accordions, carousels, banners, and other interactive elements.

For each pattern, capture the essentials:

• Name and purpose – e.g., “Primary CTA Button – used once per page for main conversion action.”
• Where it lives – link to your design system, component library, or Figma page.
• Usage rules – e.g., “Do not change text size, underline behavior, or focus outline. Do not place on non-contrasting image backgrounds.”
• Don’ts – a short list of forbidden variations that have caused problems in the past.

Tie this to how work actually happens:

• “When proposing a new landing page layout, designers must choose from these patterns or flag where a new pattern is required.”
• “Agencies may not introduce custom form components without going through the new-pattern review below.”

For new patterns, the runbook should say:

• Who reviews (e.g., accessibility owner + design + dev).
• What tests are required before approval (keyboard, color contrast, screen reader behavior).
• How approved patterns get added back into this section.

If you’ve already been through component-level remediation, this is where you can later connect to guidance like what accessibility review should confirm before a new component library starts spreading exceptions or what to clarify before an accessibility fix is marked complete across reused components in your broader accessibility topic hub.

The goal is simple: a designer under pressure to ship a new hero or form should have zero reason to invent a pattern from scratch.

---

7. Section 3 – Content rules and editorial habits that prevent regressions

Even with perfect components, content decisions can undo accessibility quickly. This section translates accessibility into editorial habits.

Focus on where marketers and editors actually make choices:

• Headings

  • Always use a single H1 per page.
  • Don’t skip levels for styling (no H2 → H4 jumps).
  • Never use headings purely for visual emphasis.

  If you’ve seen headings drift repeatedly, it’s worth connecting this section to the earlier piece on why heading and link exceptions cause recurring accessibility problems, which expands on the editorial side of this rule.

• Links and buttons

  • Link text must describe the destination or action (“Download Q4 pricing guide”), not just “click here.”
  • Don’t use identical link text for different destinations on the same page.
  • Reserve button styles for primary actions, not navigation.

• Images and media

  • Alt text describes function, not every pixel.
  • Purely decorative images use empty alt attributes, not vague labels.
  • Videos with speech require captions; audio-only content requires transcripts.

• Tables and complex layouts

  • Use tables only for actual tabular data.
  • Provide clear headings and avoid merged cells where possible.

• Error messages and inline guidance

  • Errors should identify the field, the problem, and how to fix it.
  • Don’t rely on color alone to indicate errors.

Keep this section compact—ideally a one- or two-page reference with examples of “good” and “avoid”. Then anchor it to workflows:

• “Content editors must run the content checklist before handing pages to development.”
• “Agencies must confirm these rules in their scopes of work.”
• “New hires get a 30-minute walkthrough of this section as part of onboarding.”

When content rules are explicit and trained, you stop seeing the pattern where every campaign’s copy breaks previously-agreed accessibility decisions.

---

8. Section 4 – Review cadence and triggers tied to real work

Even the best rules drift without a rhythm.

This section defines when accessibility is checked and what triggers a review.

Cadence: planned reviews

Examples that work well in practice:

• Quarterly review

  • Sample key templates and high-traffic pages.
  • Compare current state to the runbook: what’s being ignored or worked around?
  • Capture follow-up tasks and potential runbook updates.

• Annual or semi-annual audit

  • Especially after major redesigns or platform changes.
  • Feed findings into the runbook, not just a one-off remediation project.

Triggers: events that require consulting the runbook

Define what events automatically require:

• Consulting relevant sections of the runbook.
• Possibly updating the runbook itself.

Examples:

• New campaign with a bespoke layout or navigation.
• Introduction of a new component or third-party script (chat widgets, calculators, booking tools).
• Changes to the CMS or front-end framework.
• New legal or regulatory guidance from counsel.

These rhythms are how you prevent Workflow Debt from accumulating. When accessibility only appears as a reaction to complaints or audits, every fix is more expensive and more contentious than it needs to be.

---

9. Section 5 – Exception handling and escalation: how to say “yes, but safely”

Most accessibility drift doesn’t come from malice. It comes from rushed exceptions that quietly become the new normal.

Your runbook needs a clear path for exceptions so teams aren’t stuck choosing between “no” and “ship something risky.”

Define types of exceptions

• Temporary exceptions
  For short-lived campaigns where perfect compliance isn’t feasible in time. Time-box them.

• One-off exceptions
  For unique content or experiences that won’t be reused elsewhere.

• Structural exceptions
  For situations where platform or vendor limitations block compliance.

Standardize what’s required to request an exception

For example, every exception request should specify:

• What pattern or rule is being broken.
• Why an accessible alternative isn’t feasible right now.
• Expected duration (with a sunset date).
• Page(s) affected and expected traffic/visibility.
• What mitigating steps are being taken (alternative access, additional help text, etc.).

Decide who can approve what

• The accessibility owner can approve low-risk, short-term exceptions.
• A small group (owner + design + engineering + possibly legal) approves high-risk or structural exceptions, especially for checkout, account, or lead forms.

Make exceptions visible

Don’t let them live in email threads.

• Maintain an exceptions log (even a simple table) linked from the runbook.
• Include review dates; expired exceptions should trigger either remediation or a formal, documented decision to accept ongoing risk.

This is where the Operational Consequence Chain is clearest:

• Silent exceptions → inconsistent experiences → user complaints and support tickets → audit findings repeat → leadership questions past investment → heavier compliance oversight slows marketing.

A simple exception process is cheaper than that chain.

---

10. Tooling and evidence: what your runbook should say about tests, not which tools to buy

Your runbook should reference what kinds of checks are required, not hard-code a specific vendor.

Why? Because tools will change; your need for evidence won’t.

Clarify for each work type:

• Minimum checks
  For example:

  • New templates: automated scan + keyboard navigation + screen reader spot check.
  • High-traffic landing pages: automated scan + content checklist + manual checks on forms and media.
  • Minor content edits: content checklist only.

• Who runs them

  • Designers run pre-implementation checks on new components.
  • Editors run content checks before hand-off.
  • QA or a web specialist runs final checks before launch.

• Where results live

  • Link scans and issues to tickets.
  • Track recurring issues so they can feed into runbook updates.

The purpose is to keep teams from believing that “we ran a scanner” equals “we’re done.” Tools support governance; they don’t replace it.

---

11. Keeping the runbook alive: update rituals, ownership reviews, and drift signals

A stale runbook is as bad as no runbook.

Plan for it to evolve:

• Scheduled reviews
  At least twice a year, the accessibility owner should:

  • Compare recent audit or scan findings against current rules.
  • Review the exceptions log: which “temporary” exceptions are still around?
  • Ask editors and designers where the runbook is unclear or being bypassed.

• Runbook change process
  Make updates small and frequent, not giant rewrites:

  • Log changes with dates and reasons.
  • Flag major updates to relevant teams (e.g., “new rule for campaign video captions”).

Watch for drift signals that your accessibility governance is slipping:

• Same types of issues show up in every audit.
• Support tickets mention confusing forms, inaccessible PDFs, or unreadable text.
• Agencies regularly ask to break rules “just for this launch.”
• Teams quietly ship off-template experiences and fix them later, if at all.

This is Workflow Debt in motion: every unaddressed drift signal adds interest you’ll pay later—in rush fixes, legal risk, lost conversions, or brand damage.

When you see those patterns, don’t just patch the symptom. Update the runbook, the training, or the ownership model behind it.

---

12. When to bring in outside help to create or run the accessibility playbook

There’s a point where writing and enforcing a runbook with existing staff is more than the team can reasonably absorb.

Common thresholds:

• You’ve already tried to write guidelines and they were ignored.
• Ownership is fragmented and no one can realistically referee every exception.
• You operate multiple brands, languages, or regions on different platforms.
• Previous audits keep surfacing the same categories of issues.

In those cases, it can be worth bringing in a partner who treats accessibility as an ongoing governance problem, not just an audit or redesign project.

Our website accessibility services are designed to operationalize the kind of runbook you’ve just read about: clarify roles, define rules tied to your actual components and workflows, set a realistic review rhythm, and be the place teams can turn for relief when a campaign is under pressure.

If you’re not ready for a service relationship yet but want to keep building internal maturity, the posts in our accessibility topic hub expand on the themes here—ownership, workflow design, component reuse, and what to fix when patterns keep breaking.

When you are ready to formalize how this works across your site, you can always get in touch to talk through whether you need help drafting the runbook, pressure-testing an existing one, or running the ongoing reviews.

For now, a practical first step is simple: open a new document titled “Accessibility Runbook,” add the five sections from this article as headings, and write one or two decisions you’re ready to standardize under each. That’s the moment where campaigns stop reinventing the rules and start following them instead.