An accessibility monitoring report should tell a client what changed, what the agency examined, which barriers remain, and who needs to act. It should also show the limits of the evidence: a completed automated check, a completed human review, and an inaccessible or untested state are different outcomes.
For an agency, the report is the bridge between monitoring activity and the client's next decision. A developer needs a reproducible issue. A service owner needs to understand the affected task. A project lead needs an owner, a date, and any dependency preventing progress. One unexplained accessibility score cannot serve all three readers.
This guide provides a suggested monthly report structure and a fictional worked example. The example numbers describe an invented client period, not an OnChange customer, measured product performance, or a standards evaluation. Adapt the fields to the actual service scope and evidence available.
Start with the decision the client needs to make
Put the most consequential open task near the beginning. Explain what the user is unable to do, what has been verified, and what the client needs to decide. Then give enough context for the client to interpret the rest of the report.
A useful opening answers five questions: what period is covered, which service or website is in scope, what materially changed, what remains unresolved, and what action is needed next. It should link to the detailed records rather than repeat every finding.
WAI's report template identifies evaluation scope, methods, reviewers, results, and recommended actions as useful reporting information. For an ongoing service, add the relationship to earlier periods and the current status of the follow-up work.
Keep an operational monitoring update distinct from a formal conformance evaluation. If the client needs a conformance statement, establish the required scope, method, and qualified evaluation for that purpose. W3C's WCAG-EM overview explains that evaluation process; a month of monitoring alerts does not complete it automatically.
Keep five reporting units separate
Before calculating any totals, define what the report counts. A page, event, review item, finding, and retest describe different things. Mixing them can make the same shared issue look like rapid deterioration or make a large coverage gap disappear inside a reassuring total.
Scroll horizontally to see all columns.
| Unit | Working definition | Example |
|---|---|---|
| Monitored subject | An agreed page, component, or state observed under stated conditions | The expanded mobile navigation on a named page |
| Change event | A recorded difference between comparable captures | A navigation markup change on one monitored subject |
| Review item | An agency investigation that may group related events | Review the shared navigation update across selected contexts |
| Confirmed finding | An observed barrier with a stable issue reference | A control cannot be reached in the tested keyboard sequence |
| Retest | A new evaluation of a finding after a claimed fix or relevant change | Repeat the agreed task against the released version |
One review item may contain several events and produce no confirmed finding. One finding may appear in several observed locations. One issue may need multiple retests before it is resolved. Preserve those relationships so the reader can follow the totals back to evidence.
Describe the coverage before the findings
Record the agreed monitored subjects, relevant states, environments, and exclusions. Give the report period with a timezone, identify the release or capture references used, and say which checks were automated or performed by a person.
Where a planned check did not succeed, report the failure and its consequence for coverage. A blocked account, unavailable vendor system, or missing state is not a successful accessibility result. Name the action needed to restore access or obtain the evidence.
Describe scope movement since the previous period. If the client added a language, replaced the booking flow, or removed several pages, explain whether the monitoring and human-review samples changed too. Otherwise, month-to-month totals can look comparable while representing different parts of the service.
Use the audit scope guide for the detailed boundary and the monitoring service guide for ongoing responsibilities. The monthly report should reference those records and explain changes rather than silently redefine the service.
A worked monthly summary for an agency client
The following example uses a fictional appointment-booking website and invented records. It demonstrates report structure and arithmetic only. It does not describe a tested website or contain real evaluation evidence.
Executive update
During the example month, the agency monitored 12 agreed page-state subjects and recorded 12 candidate change events. These were grouped into eight review items. Five items received a documented review decision; three remain unresolved because of incomplete evidence, vendor access, or pending manual work.
One newly confirmed barrier prevents the scoped keyboard route through the booking dialog. The client booking team owns the repair. The next action is to provide a testable release and confirm the interim support route with the service owner. Other journeys and input methods have not been inferred from that result.
The finding register opened with seven unresolved issues and closes with seven. That equal total does not mean nothing happened: two new findings were confirmed, one previously closed finding was reopened, and three findings were resolved through retesting. Two of those successful retests concerned work carried forward from an earlier period.
Review queue
Scroll horizontally to see all columns.
| Review item | Candidate events | Current decision and next action |
|---|---|---|
| R1: booking dialog update | 2 | New barrier confirmed; booking team to provide a fix |
| R2: help article edits | 1 | Review complete; no barrier found in the edited content examined |
| R3: form feedback replacement | 3 | New finding recorded, then fixed and verified in a later retest |
| R4: shared navigation change | 1 | Previously closed finding reproduced and reopened |
| R5: contact details update | 2 | Review complete; earlier scoped interaction evidence remains applicable with rationale |
| R6: styles unavailable in comparison | 1 | Evidence inconclusive; obtain a comparable capture |
| R7: vendor booking state | 1 | Awaiting authorized test access from the client vendor manager |
| R8: new consent interaction | 1 | Manual interaction review scheduled; no conclusion yet |
The event column totals 12. R1 through R5 account for the five completed review decisions. R6 through R8 account for the three unresolved reviews. A completed investigation can still leave a confirmed defect open, as R1 and R4 do. Investigation status and remediation status must therefore be reported separately.
This example is deliberately more informative than “five checks passed.” It shows that some completed work discovered a barrier, one finding was retested successfully, and several questions still lack enough evidence for a conclusion.
Reconcile the finding register
Use stable finding identifiers across periods. Do not create a new issue merely because its title, page address, or assignee changed. When several observations share a cause, retain the observed locations and explain the grouping.
For the fictional period above, the register reconciles as follows:
Scroll horizontally to see all columns.
| Finding movement | Count | Interpretation |
|---|---|---|
| Unresolved at the start | 7 | Carried forward from the previous period |
| Newly confirmed | +2 | Includes the R1 and R3 findings |
| Reopened | +1 | The earlier R4 finding is reproducible again |
| Resolved after retest | -3 | R3 plus two earlier findings |
| Withdrawn or no longer applicable | 0 | No removal without a documented reason |
| Unresolved at the end | 7 | 7 + 2 + 1 - 3 = 7 |
A finding opened and resolved in the same period appears in both movements, as R3 does. That is useful activity to report. If a finding is withdrawn because the relevant function was removed, record the reason separately from a verified fix. Removing a feature and making that feature accessible are different outcomes.
Show essential-task barriers individually even when the report also includes totals. A balanced register can conceal the arrival of a serious new problem. The client needs the consequence and next action, not only an unchanged number.
Give every open item an actionable record
The detailed issue should identify the tested location and state, the affected user task, the steps performed, the observed result, and the expected behavior. Include the relevant standard reference when the evaluator has established that relationship.
Name the environment actually used: browser and version, operating system, assistive technology where applicable, viewport or zoom conditions, and the tested release. A screenshot can support the explanation, but behavior needs a written observation or appropriate recording as well.
Assign an implementation owner and a review owner where those roles differ. Record the next action and its target date. If the agency is waiting for access or a vendor response, the item should say who is responsible for removing that dependency.
The evidence handoff guide provides a fuller issue format. For the monthly report, link to that source record and give a concise status. Copying detailed findings into several disconnected documents makes later corrections harder to trace.
Explain what was retested and what the result covers
A fix announcement is a reason to perform a retest. Record the version checked, the reproduced task, the reviewer, the date, and the outcome. Preserve the original finding so a future reader can understand what changed.
Use outcomes that describe the observation: verified fixed in the tested scope, partially resolved, still reproducible, or unable to verify. If another issue appears during the retest, relate it to the existing finding where appropriate without hiding a separate barrier under a “fixed” label.
Be specific about reach. “The revised dialog completed the agreed keyboard task on the tested booking page” is a bounded result. It should not silently become a conclusion about every dialog, every browser, or every assistive technology supported by the client.
Automated results belong beside the human evidence, with their own method and run outcome. WAI's evaluation overview explains why tools alone cannot determine a site's accessibility. A clean scan can be useful evidence for the checks it performed, while manual questions remain open.
Choose measures that show whether the service is working
Use a small set of measures that the client can act on. Define each denominator, exclude nothing silently, and explain changes to the sample or method.
For capture coverage, report successful comparable captures against the checks that were planned, with failed attempts visible. For review work, show completed decisions against the items due for review and list overdue work. For remediation, show unresolved findings, their age, and verified retests. Those measures describe the service process; none measures the percentage of the website that is accessible.
Response time needs a clear starting point and working calendar. Time from an automated event to first triage differs from time from a confirmed finding to a verified fix. The agency may control one interval while the client or vendor controls part of the other. State which interval is reported.
Only compare periods whose coverage and methods support the comparison. A tool rule update, newly reachable account area, or expanded manual sample can increase findings without showing that the underlying website became worse. Explain the change before presenting a trend.
Make the report itself usable and appropriate to share
Provide descriptive headings, meaningful links, readable tables, and a text explanation of any chart. If a client requests a PDF, check the exported document's structure and reading order; a readable webpage does not establish that its export is accessible.
Keep the executive account understandable without requiring every reader to inspect raw markup. Offer technical details through linked issue records. Make sure recipients can access the intended evidence and that links remain available for the agreed reporting period.
Review attachments for unrelated account data, credentials, personal information, and internal notes before delivery. Use the client's actual access and retention requirements. The public examples in the accessibility decision library use authored fixtures; real client evidence needs its own sharing decisions.
Report delivery should include a named contact and the next review date. If the report asks the client to authorize vendor access or supply a release, make that request easy to find and track its completion in the following period.
A reusable outline for the next client report
Use these sections as the report's starting structure. Fill them with actual records, and retain “not evaluated” or “unable to verify” wherever the evidence does not support a conclusion.
- Period and scope: client service, reporting dates and timezone, monitored subjects, manual sample, environments, exclusions, and changes since the prior period.
- Client decisions: affected essential tasks, immediate actions, accountable owners, and target dates.
- Coverage and run outcomes: planned checks, comparable evidence obtained, failures, and unresolved access or state gaps.
- Change review: grouped events, decisions completed, outstanding reviews, and the rationale for selecting retests.
- Finding movement: opening unresolved issues, new findings, reopened items, verified fixes, removals with reasons, and the reconciled closing register.
- Retest evidence: issue references, tested versions and conditions, observations, reviewers, and remaining limits.
- Next period: planned releases, sample changes, scheduled evaluation, dependencies, and the next client review.
The OnChange accessibility workflow can support evidence, review work, and client reporting. The report's conclusions still depend on the agency's scope, actual evaluation, and recorded decisions. Use the monitoring record to make those decisions inspectable.
Questions about agency monitoring reports
Should the report include an accessibility score?
Only when the method, denominator, and meaning are clear enough to be useful. Keep the actual findings, scope gaps, and actions visible. Do not turn an automated score into an implied overall conformance result.
How should an agency describe a month with no new findings?
State which checks succeeded, which subjects and states were reviewed, and what remains outside that work. Report existing unresolved findings and failed checks as well. “No new findings in the work described” is a narrower conclusion than a statement about the entire website.
How often should the agency send the report?
Agree a cadence that suits the client's release and decision process. A monthly summary may be useful for planning, while a confirmed essential-task barrier can need a separate prompt escalation. The reporting schedule should not delay an agreed urgent response.