How web agencies add accessibility monitoring to client retainers
Clients are starting to ask their agencies about accessibility. A site redesign goes live, someone on the client's team reads something about the European Accessibility Act, or their legal team flags the topic. The agency gets the question and has to give an answer.
The two common answers -- "hire a manual auditor" ($3K-$25K per engagement) or "install an overlay widget" (documented to fail screen readers and carry its own legal exposure) -- do not work well in an ongoing retainer relationship. Manual audits are a one-time snapshot that ages quickly as the site changes; overlay widgets are the opposite of what a quality-conscious agency wants to stand behind.
This guide explains how recurring automated accessibility monitoring fits into an agency service model: what the workflow looks like, what the reports contain, and how to structure it for clients.
The scope problem, stated honestly
Before anything else: automated scanning does not replace manual accessibility testing. Automated tools test for the rules that can be verified programmatically -- missing alt text, unlabeled form fields, ARIA structure errors, color contrast ratios, keyboard focus visibility. Industry-wide, that covers roughly 30-57% of WCAG issue types. The rest require a human tester with a screen reader to verify.
For most agency clients, automated monitoring is the right starting point. The issues it finds -- the ones in that 30-57% -- are also the ones that appear most often in the findings from real site audits and in the accessibility complaints that actually reach legal teams. A client that fixes its unlabeled product buttons, missing form labels, and contrast failures has addressed the most common failure patterns, even if a full manual audit would surface additional issues.
The agency's role is to scope this correctly. "Monthly automated accessibility monitoring" is an honest description. "Full WCAG compliance" is not something automated scanning can verify, and claiming it creates liability the agency does not want.
What a white-label monitoring setup looks like
In a white-label arrangement, the agency is the client relationship owner. The scanning service runs in the background; the client sees reports under the agency's branding, not the scanner's.
The typical setup:
- The agency registers client sites for monthly scanning (URL, crawl depth, scan schedule).
- Each month, the scanner crawls the site, runs accessibility tests against every discovered page, and generates a report branded with the agency's logo, name, and color scheme.
- The report goes to the agency inbox, not directly to the client. The agency reviews it, annotates it if needed, and delivers it -- by forwarding the pre-written email, sending the HTML report link, or incorporating the findings into a monthly retainer summary.
- The client relationship remains entirely with the agency.
No code is installed on the client's site. The scanner fetches pages the same way a search engine crawler would. There is nothing to maintain, nothing to break on a site update.
The diff report: what changes between scans
A single scan tells you what is broken today. A diff report tells you what changed since last month -- which is the more useful signal for ongoing maintenance. When a client's development team ships updates, the diff shows whether the changes introduced new problems, fixed old ones, or left the baseline unchanged.
A diff report groups findings into four categories:
| Category | What it means | Action |
|---|---|---|
| Fixed | A finding from the previous scan is no longer present | Good news to share; confirms the fix landed correctly |
| New | A finding that was not present in the previous scan appeared this month | Requires investigation; often introduced by a recent code deploy |
| Regressed | A finding that was previously fixed has reappeared | Highest priority; the fix did not hold, possibly overwritten by a template update |
| Unchanged | Known findings from the previous scan are still present | Backlog; no urgency if not in the active fix queue |
The "regressed" category is particularly useful in e-commerce, where theme updates, plugin installs, and seasonal template swaps routinely overwrite previously fixed elements. A color swatch button that was labeled correctly last month can lose its accessible name if the theme update ships a fresh component template that does not carry forward the fix. Without a diff report, that regression is invisible until someone notices it manually.
A realistic monthly workflow for an agency
Once clients are enrolled, the monthly cycle is low-touch for the agency:
- Scan runs automatically on the scheduled date. No agency action required.
- The diff report arrives in the agency's inbox. The email body is pre-written and ready to forward; the HTML report is linked. Review takes 5-10 minutes for a typical small-business site (20-50 pages).
- The agency delivers the report to the client, typically as part of the monthly retainer update. New or regressed findings can be flagged for the development queue; fixed findings are good-news content that demonstrates the retainer is producing measurable results.
- If the client's dev team needs fix guidance, the report includes specific HTML examples tied to the actual markup on the affected page -- not generic documentation, but the element and the fix for that element on that page.
The client-facing framing for most agencies is straightforward: "As part of your monthly maintenance retainer, we run an automated accessibility scan on your site and review the results. Each month you get a report showing what we found, what changed from the previous month, and what your team should address. We handle the monitoring; you handle the dev fixes."
How agencies typically structure the billing
There is no single right model. What tends to work depends on how the agency bills for maintenance retainers generally.
Bundle into an existing retainer
The most common path: accessibility monitoring is included in the agency's monthly maintenance fee, which already covers hosting oversight, plugin updates, uptime monitoring, and other ongoing services. The agency pays the wholesale scan cost from the retainer margin and presents accessibility monitoring as a value-add, not a separate line item. This works well when the client's retainer fee has room and the scan cost is small relative to the total.
Standalone accessibility monitoring add-on
Some agencies prefer to offer it as an explicit line item: "$150/month -- accessibility monitoring, monthly diff report, fix guidance." This makes the value visible and billable separately, which matters for agencies whose retainers are tightly scoped. It also makes it easy to add to clients who are not already on a maintenance retainer.
Baseline audit plus ongoing monitoring
A common onboarding pattern: start with a one-time baseline audit (scans all pages, identifies every automated finding, produces the initial report), then transition to monthly diff monitoring at a lower recurring fee. The baseline is a discrete deliverable the agency can bill for; the diff monitoring is recurring revenue that follows. Clients who have seen the baseline report and understand what was found are easier to retain on monitoring because the value is concrete.
What the client is actually paying for
When clients ask why they should pay monthly for accessibility monitoring rather than a single audit, the meaningful answer is about change. A site audit on January 1 is accurate on January 1. By April, the site has had a theme update, a new plugin, seasonal sale templates, and six product launches. The audit is four months stale and the findings are no longer reliable.
Accessibility monitoring is a signal on every deploy: did this change introduce new problems? The diff report does not replace developer discipline, but it surfaces regressions that would otherwise go unnoticed until a user complaint or external audit catches them. For e-commerce clients who ship changes frequently, that continuous signal is what they are paying for.
What monitoring does not cover
For completeness: automated scanning covers the majority of programmatically-testable accessibility rules but cannot test everything. Screen reader behavior on dynamic interactions (live regions, focus management after JavaScript state changes, custom widget patterns built outside standard HTML semantics) requires manual testing. Cognitive accessibility -- whether the site is comprehensible to users with cognitive disabilities -- is not measurable by automated tools at all.
For clients who need a comprehensive audit that covers manual testing, refer them to accessibility specialists who do screen-reader-based audits. That work is complementary to automated monitoring, not competing with it. The monitoring catches the automated failures on an ongoing basis; the manual audit provides deeper coverage at a point in time.
Starting with a sample report on a client site
The easiest way to evaluate whether this fits a client's situation is to run a scan and see the actual output. A homepage scan on a Shopify or WooCommerce store takes a few minutes and produces a report showing exactly what would appear in the monthly monitoring reports: severity-grouped findings, element locations, WCAG references, and code-level fix examples.
If you want a sample scan and branded report on one of your client sites, email hello@barrierscan.com with the URL. We will run it and send back the report. No account needed, no commitment.