Accessibility projects don’t fail because agencies don’t care, they fail because the scope is unclear.

As accessibility becomes a standard part of digital delivery, agencies are increasingly expected to define what’s included, what’s excluded, and what “done” actually means. When this isn’t handled carefully, accessibility becomes a source of risk rather than confidence.

This guide explains how agencies can scope accessibility work clearly, define deliverables responsibly, and avoid the most common overcommitments that create delivery and legal exposure.

Why accessibility scope is so often unclear

Accessibility scope tends to break down because:

  • WCAG is broad and technical
  • clients ask for reassurance, not details
  • agencies want to be helpful
  • accessibility touches design, dev, content, and QA

Without structure, scope becomes implicit — and implicit scope is dangerous.

Confident agencies make accessibility explicit.

What agencies should always define in scope

1. WCAG version and level

Always state:

  • WCAG 2.2
  • Level AA

Avoid vague language like “WCAG compliant” without detail.

2. What’s being assessed

Define what accessibility applies to:

  • page templates
  • components
  • journeys (e.g. checkout, onboarding)
  • documents (if included)

Avoid phrases like “the whole site” unless that’s genuinely what you mean.

3. What’s not included

Explicit exclusions protect everyone.

Common exclusions include:

  • third-party tools
  • user-generated content
  • legacy documents
  • future content updates

Clear exclusions reduce friction later.

Accessibility deliverables agencies can stand behind

Design-stage deliverables

Through design-stage accessibility guidance, agencies can provide:

  • design accessibility reviews
  • component guidance