Applying WCAG 2.2 in Agency Delivery: A Practical Guide
WCAG 2.2 is clear on what accessibility requires, but far less clear on how agencies should apply it in real delivery workflows.
For many digital agencies, WCAG becomes a source of friction not because the guidelines are unreasonable, but because they’re often introduced late, interpreted inconsistently, or treated as a checklist rather than a delivery framework.
WCAG often fails not because of complexity, but because ownership is unclear, particularly for accessibility for delivery teams managing competing priorities.
This guide explains how agencies can apply WCAG 2.2 Level AA across the full delivery lifecycle — from proposal and design through development, verification, and post-launch maintenance — without slowing delivery or increasing risk.
Why WCAG feels hard in practice
Most agencies don’t struggle with the principles of WCAG. They struggle with:
- translating guidelines into design decisions
- defining “done” for developers
- explaining accessibility outcomes to clients
- proving conformance without over-claiming
WCAG wasn’t written for agencies, it was written as a standard. Applying it successfully requires structure, interpretation, and consistency across teams.
1. WCAG in proposals and scoping
WCAG problems often start before delivery begins.
What agencies should commit to
When scoping accessibility, agencies should be explicit about:
- WCAG version (2.2)
- Conformance level (Level AA)
- Scope (templates, components, journeys)
- Known exclusions or assumptions
Clear scoping reduces downstream risk.
What agencies should avoid
Avoid promising:
- “100% accessibility”
- “full compliance”
- guarantees beyond scope
Instead, position WCAG as a defined delivery outcome with evidence.
This is where design-stage accessibility guidance helps agencies set expectations early and scope accessibility responsibly.
2. WCAG in design (before development begins)
Accessibility is cheapest and easiest to address during design.
What WCAG means in design
At this stage, WCAG informs:
- colour contrast
- text sizing
- heading hierarchy
- focus states
- component behaviour
Design reviews should focus on patterns and systems, not individual pages.
Practical agency approach
- Review Figma files for WCAG risk early
- Define accessible component rules
- Document accessibility decisions for developers
Design-stage alignment prevents rework and conflicting interpretations later.
3. WCAG in development
This is where WCAG becomes tangible.
What developers need
Developers don’t need WCAG theory — they need:
- clear acceptance criteria
- examples of expected behaviour
- consistency across components
WCAG success depends on how requirements are consumed by teams, especially accessibility for developers working within component-based systems.
WCAG should be translated into:
- keyboard behaviour expectations
- semantic HTML requirements
- ARIA usage guidance (where appropriate)
Common agency mistake
Leaving WCAG interpretation to QA alone.
Accessibility works best when:
- developers understand intent
- issues are caught during build
- fixes are validated as part of delivery
4. WCAG in testing and verification
Testing is where agencies move from intent to evidence.
Manual vs automated testing
Automated scans are useful for:
- coverage
- repeatability
- regression detection
But they must be paired with:
- manual keyboard testing
- assistive technology testing
- human judgment
What a WCAG conformance audit actually does
A proper audit:
- evaluates real user interaction
- prioritises issues by impact
- maps findings to WCAG success criteria
- produces developer-ready guidance
This is the role of WCAG conformance audits, not just identifying issues, but explaining them clearly.
5. WCAG in reporting and evidence
Clients don’t want raw findings, they want confidence.
What good WCAG reporting includes
- prioritised issues
- plain-language explanations
- WCAG references
- remediation guidance
- clear scope statements
Reports should support:
- internal remediation
- stakeholder communication
- defensible delivery decisions
Avoid legal language or absolute claims. Focus on evidence and transparency.
6. WCAG post-launch: maintaining conformance
Accessibility doesn’t end at launch.
Why regressions happen
Post-launch changes introduce risk:
- new content
- CMS updates
- feature releases
- third-party integrations
Without oversight, accessibility can degrade quickly.
Practical agency solution
Agencies that maintain accessibility use ongoing WCAG monitoring to:
- detect regressions early
- track trends over time
- support retainers and continuous improvement
- maintain confidence as standards evolve
7. Common agency mistakes applying WCAG
Even experienced teams fall into traps:
- Treating WCAG as a checklist
- Introducing accessibility too late
- Over-engineering fixes
- Under-scoping audits
- Avoiding documentation
The most successful agencies treat WCAG as a delivery framework, not a compliance hurdle.
Where IncluD fits
IncluD supports agencies across the full WCAG delivery lifecycle.
From design-stage accessibility guidance that informs early decisions, through WCAG conformance audits that provide clear, defensible evidence post-build, to ongoing WCAG monitoring that maintains accessibility as sites evolve.
All of this is delivered through a purpose-built agency accessibility platform, designed to integrate into real-world delivery workflows without disruption.
Key takeaways for agencies
Agencies succeed with WCAG when they:
- scope accessibility deliberately
- apply WCAG early and consistently
- support developers with clarity
- report outcomes transparently
- maintain accessibility over time
When applied thoughtfully, WCAG becomes a confidence multiplier, not a delivery risk.
