Accessibility monitoring is the ongoing process of observing a website, identifying changes that may affect disabled users, and arranging the evaluation or remediation those changes need. For an accessibility agency, its value is continuity: the client can see how an earlier audit, a new release, and the next review relate to each other.
A useful service combines scheduled checks, preserved change evidence, human evaluation, and an accountable response. Running a scanner repeatedly covers only part of that process. W3C explains that tools assist evaluation, while knowledgeable human review is needed to determine accessibility. WAI evaluation overview.
This guide proposes an operating model for agencies that support client websites after an audit or remediation project. The example schedules and service boundaries are planning suggestions. They are not a prescribed W3C monitoring frequency or a promise about what any software detects.
Why an accessibility audit needs a maintenance plan
An audit describes the interface and conditions that were evaluated. A client can keep the same domain, design, and page titles while changing the details on which those results depended. A content editor replaces an image. A shared component receives a new interaction. A third-party booking provider updates its widget. Each change can introduce a question the original evaluation did not answer.
The agency's practical problem is knowing when that question exists. Without a maintenance process, the next reviewer must reconstruct the release history, locate the original evidence, and establish which version a client is discussing. Change monitoring can preserve a useful starting point for that investigation.
WAI's planning and management guidance places evaluation, responsibility, monitoring, and feedback throughout the work of sustaining accessibility. An agency can turn that principle into a repeatable service: agree the scope, detect relevant movement, investigate the user effect, and record what happens next.
Explain the value to clients through their actual tasks. A person needs to book an appointment, understand a form error, or navigate to support. The service helps the team notice when a change may put one of those tasks at risk and gives someone responsibility for reviewing it.
Separate the four kinds of work
Clients often use “monitoring” to describe several different activities. Naming those activities in the service description prevents a successful automated check from being mistaken for a completed evaluation.
Scroll horizontally to see all columns.
| Activity | Question it answers | Agency deliverable |
|---|---|---|
| Website change detection | What captured content, structure, style, or state changed? | A before-and-after record with capture conditions |
| Automated accessibility checking | Which machine-checkable findings appeared in the checked state? | Results with rule, location, tool version, and run outcome |
| Human accessibility evaluation | How does the affected task work for the people and conditions in scope? | Reproducible observations and a qualified conclusion |
| Remediation and retesting | Was the reported problem addressed in the released interface? | A fix reference and a new test result |
A client might buy all four from one agency or divide them between an evaluator and a development partner. Either arrangement needs an explicit handoff. An alert that reaches a shared inbox but has no reviewer is an unfinished service.
Use the manual and automated testing guide to describe method coverage in more detail. Keep the monitoring description focused on how work moves between methods and people.
Define coverage in pages, states, and tasks
Start the monitoring scope with the client outcomes that matter. Public information, account access, booking, payment, and support may have different owners and different capture requirements. A list of URLs alone will miss distinctions such as a closed menu versus an open menu, or an empty form versus an invalid submission.
For each monitored subject, record its URL or route, relevant state, capture method, device or viewport conditions, and known exclusions. Record how the state is reached. A scheduled check that never opens a dialog cannot support conclusions about the dialog's current keyboard behavior.
Maintain three separate lists: the website inventory, the monitored sample, and the human evaluation sample. Some entries will belong to all three, but the counts are not interchangeable. Also record missing coverage, including authenticated areas, unavailable test accounts, third-party flows, documents, and locales that have not been agreed.
For a fictional booking service, a starting matrix might look like this:
Scroll horizontally to see all columns.
| Subject | State to preserve or review | Follow-up owner |
|---|---|---|
| Global navigation | Desktop links and the expanded narrow-screen menu | Agency reviewer and client platform team |
| Appointment form | Initial, invalid, corrected, and confirmation states | Agency reviewer and booking team |
| Help articles | Edited headings, links, and meaningful images | Content owner with agency escalation |
| External booking widget | Agreed entry and completion path, where access permits | Client vendor manager |
This is an illustrative scope, not a claim that those checks cover every accessibility requirement. Revisit the audit scope when new functionality or a substantially different interface appears.
Build a baseline people can interpret
A monitoring baseline is a reference for comparison. It may contain known problems. Calling a captured page a baseline does not mean that the page passed an accessibility evaluation.
Attach the relevant audit and remediation records to the starting version. Keep known findings open, identify evidence that has been reviewed, and mark states that have not been evaluated. Record when the baseline was captured and whether it represents staging or production. A reviewer needs to distinguish “unchanged since a known failure” from “changed since a successful retest.”
For repeatable captures, agree the account state, viewport, locale, consent choice, and any loading conditions that matter. Avoid making a screenshot comparison appear stable by hiding the very component that needs review. Where content is deliberately excluded, explain what decision that exclusion serves and what coverage it removes.
The monitoring brief provides an editable way to agree subject identity, capture conditions, exclusions, and ownership before activation. Preserve the approved version with the client's service records so a later reviewer can understand why the monitor was configured that way.
Choose a cadence the team can actually support
Use both scheduled checks and change-triggered work. Scheduled checks help observe edits that arrive outside the main release process. Release-triggered review gives the agency a reason to reconsider known evidence after a planned implementation change.
An illustrative service rhythm could include frequent checks of selected public pages, a review after a material release, a weekly review queue, and a monthly client discussion. The appropriate frequency depends on how often the site changes, the consequences of a missed barrier, access constraints, and the agency's staffed response window.
Detection frequency and response time are different commitments. A tool may check overnight while the agency reviews during agreed working hours. State who handles a potentially blocked essential task outside that window. Do not imply continuous human supervision just because the software runs on a schedule.
Also schedule broader reassessment. A stream of narrow change reviews can leave an old sampling assumption unexamined. A new customer journey, template family, vendor, or major redesign should trigger a scope discussion even if the existing monitors have produced few alerts.
Make triage a decision, not another notification
The first reviewer should establish whether the capture succeeded, whether the expected subject is present, and what question the change raises. A login wall, missing asset, or different consent state can make two captures incomparable. Keep that as a capture problem until it is understood.
For comparable evidence, record the likely user task affected and the reach of the changed component. One shared navigation update can produce many page events while requiring a coordinated investigation. Group related evidence without losing the specific pages and states that were observed.
Use explicit outcomes: review required, no relevant change found within the examined scope, capture inconclusive, or outside the current service boundary. A changed page is not automatically an accessibility defect. Equally, a visually unchanged page is not proof that programmatic relationships or keyboard behavior stayed the same.
The guide to changes that affect accessibility explains how different change signals lead to different review questions. Once an issue is confirmed, assign its owner, next action, and retest conditions before closing the triage item.
Agree the agency and client responsibilities
Monitoring spans organizational boundaries. The agency may detect and evaluate a change while a client development team, content editor, or vendor must implement the repair. Put those responsibilities in the operating plan.
An agency lead can own the review queue and reporting. A client release owner can supply planned changes and confirm the deployed version. Development and content owners can address the issue in the system they control. A client service owner can decide on an interim route when an essential task is blocked.
Define what starts a new piece of work. Investigation, manual testing, remediation, independent review, and a broader re-audit may have different allocations. State how the client approves work that exceeds the agreed scope. This keeps an agency from quietly absorbing an expanding website while the client assumes every new journey is already covered.
If several suppliers share a component, keep one coordination owner and separate evidence for each affected implementation. A supplier saying that a fix is deployed starts the retest; it does not close the accessibility finding by itself.
Report progress with useful denominators
A monthly report should explain what was monitored, what changed, what was reviewed, what remains unresolved, and what the client needs to decide. Keep automated findings, confirmed barriers, and incomplete checks separate.
Raw issue counts can be misleading. One shared defect may appear on many pages. A lower finding count may follow a smaller sample, a failed capture, or a tool update. Record changes to the monitored set and evaluation method before drawing a trend.
Useful measures include the number of review items awaiting triage, the age of unresolved essential-task barriers, the number of agreed retests completed, and the share of scheduled captures that succeeded. Describe the denominator and the reporting period for each. None is a percentage of overall accessibility.
Use the agency client report guide for a worked example that reconciles change events, review decisions, findings, and coverage gaps. Its purpose is to support a client decision with traceable evidence.
Keep disabled users in the feedback loop
Provide a route for people to report difficulty completing a task, and include that feedback in triage even when no automated finding accompanies it. Record enough context to investigate without asking for unnecessary personal information.
Plan evaluation with disabled people at appropriate points in the service. WAI describes how involving users in evaluation helps teams understand real use, while keeping conclusions tied to the participants and conditions involved. One successful session does not represent every disability, assistive technology, or task.
The agency can use recurring themes from reviews and user feedback to recommend improvements to content training, component design, or release checks. Record those recommendations separately from confirmed defects so the client understands whether the next action is a repair, research, or a process change.
Where OnChange fits in the agency workflow
OnChange can preserve website change evidence and support automated accessibility results, review work, and client reporting. Its optional agency assurance workflow lets teams link monitors to recorded evidence and review the impact of subsequent captured changes. See the accessibility monitoring overview for the product workflow.
Precise evidence comparison remains bounded by what was captured and linked. An unchanged target does not extend an evaluation to an untested page, journey, or assistive technology. Affected or uncertain evidence needs a reviewer decision, and manual evaluation remains part of the agency's service.
Begin with a scope the team can maintain, one named review owner, and a complete path from observation to retest. Expand the service when the evidence and response capacity support it.
Questions agencies hear from clients
Can ongoing monitoring replace our accessibility audit?
It serves a different purpose. Monitoring helps identify changes and maintain a review process between evaluations. An audit establishes findings and conclusions for an agreed scope and method. Use both when the service needs that initial assessment and continuing maintenance.
Does a quiet monitoring report mean the website is accessible?
A quiet report means the configured checks did not produce a qualifying result during the stated period. Review successful capture coverage, exclusions, and manual work before interpreting it. It does not establish that every page or task is accessible.
How should an agency price the ongoing work?
Estimate the monitored subjects, state preparation, change volume, review effort, reporting, and retests the service includes. Define what happens when the website expands or a major release needs broader evaluation. A page count can inform the estimate, but it does not describe all of the work.