WCAG conformance is not a destination. It is a continuous state that requires active maintenance after remediation is completed. New content, design updates, third-party integrations, and code changes can all reintroduce accessibility issues. Organizations that treat remediation as the finish line will lose conformance over time, often without realizing it.
The path forward involves recurring audits, scan monitoring, team training, and an accessibility policy that keeps conformance part of your operational rhythm.
| Practice | Why It Matters |
|---|---|
| Recurring accessibility audits | New and updated content must be evaluated against WCAG 2.1 AA or WCAG 2.2 AA to confirm conformance is maintained |
| Automated scan monitoring | Scans flag approximately 25% of issues and serve as an early warning system between audits |
| Staff training | Content authors, designers, and developers who understand WCAG create fewer issues from the start |
| Accessibility policy | A documented policy keeps accessibility embedded in workflows rather than dependent on individual memory |
| Issue tracking | Tracking new issues in a centralized system prevents regressions from going unnoticed |
Why Does Conformance Degrade After Remediation?
Websites and web apps are not static. Every blog post, product update, landing page, or feature release introduces new content that may not conform to WCAG. A site that was fully conformant at the end of a remediation project can accumulate dozens of new issues within a few months.
Third-party components are another common source. Chat tools, analytics scripts, embedded forms, and social media feeds operate outside your direct control. When these components update, they can introduce accessibility issues your team did not create and may not notice.
Even routine CMS changes, like swapping out an image without adding proper alt text, or restructuring a page layout in a way that breaks heading hierarchy, will erode conformance. The pattern is predictable: without a maintenance plan, conformance degrades steadily.
Schedule Recurring Accessibility Audits
A manual accessibility audit is the only way to determine WCAG conformance. Accessible.org recommends auditing at least annually, and more frequently if your digital asset undergoes regular content or feature updates.
The audit identifies issues across the full scope of WCAG success criteria, including those that no automated tool can detect. After your initial remediation, follow-up audits confirm whether fixes held and whether new content meets the standard.
Organizations with active development cycles often benefit from auditing twice per year. Those with relatively stable content may find annual audits sufficient. The right cadence depends on how frequently your site changes.
Use Automated Scans as an Early Warning System
Automated scans are not a substitute for audits. Scans only flag approximately 25% of issues. But between audits, they serve a valuable role as a monitoring layer that catches certain regressions quickly.
Running scans on a regular schedule, weekly or monthly, gives your team visibility into new issues as they appear. Missing alt text, empty links, broken form labels, and color contrast gaps are the kinds of things scans detect well. When a scan flags new issues that did not exist after your last audit, that is a signal worth investigating.
The Accessibility Tracker Platform includes scan and monitoring functionality that integrates with your audit data, so your team can see both manual audit results and scan results in one place.
Train Your Team on Accessibility
Most conformance regressions are introduced by people, not technology. A content editor uploads an image without alt text. A designer creates a button with insufficient color contrast. A developer builds a modal that traps keyboard focus.
Training is the most effective way to prevent these issues at the source. It does not need to be exhaustive. Content authors need to understand alt text, heading structure, link purpose, and document formatting. Designers need to understand color contrast ratios and focus indicators. Developers need to understand ARIA, keyboard navigation, and semantic HTML.
Accessible.org offers role-specific WCAG training that covers exactly what each team member needs to know, without requiring everyone to learn the entire standard.
Document an Accessibility Policy
A written accessibility policy turns your commitment into a process. It should specify which WCAG version and level your organization targets (WCAG 2.1 AA or WCAG 2.2 AA), who is responsible for accessibility across teams, and what happens when new content is published or new features are deployed.
Good policies also address procurement. When your organization brings in third-party tools or services, the policy should require an ACR or equivalent documentation that demonstrates conformance. This prevents new tools from undermining the accessibility work you have already completed.
For organizations subject to ADA compliance requirements, particularly under Title II, a published accessibility policy is a practical necessity. It demonstrates ongoing commitment and provides a framework your team can follow without guessing.
Track Issues in a Centralized System
After remediation, new issues will appear. That is expected. What matters is how quickly they are identified and addressed. A centralized tracking system keeps all accessibility issues visible, assigned, and prioritized.
Spreadsheets work for small teams. For larger organizations or those managing multiple digital assets, a dedicated tracking platform offers better visibility. Accessibility Tracker was built for this workflow. It maps audit results, scan data, and remediation progress into a single view so your team always knows where things stand.
Issues that go untracked tend to accumulate. Tracking them in one place makes it possible to address regressions before they compound.
Integrate Accessibility into Your Development Workflow
The most sustainable approach to maintaining conformance is building accessibility into your existing processes rather than treating it as a separate activity.
This looks different for every organization, but common patterns include: adding accessibility acceptance criteria to development tickets, including accessibility checks in QA processes, requiring alt text and heading structure in content publishing guidelines, and reviewing third-party components for accessibility before integration.
When accessibility is part of how your team already works, maintaining conformance requires less dedicated effort over time. The goal is to prevent issues rather than discover and fix them after the fact.
What Does a Realistic Maintenance Plan Look Like?
A practical maintenance plan combines several of these practices into a repeating cycle. Annual or semi-annual audits provide the definitive conformance check. Monthly or weekly scans catch regressions between audits. Ongoing training keeps your team producing conformant content. A policy document ties it all together.
The cost of maintaining conformance is significantly lower than the cost of a full remediation project. Think of it as the difference between regular maintenance and a major overhaul. Organizations that invest in ongoing maintenance spend less over time and carry less legal risk under ADA compliance and EAA compliance requirements.
How often should we get an audit after remediation?
At minimum, once per year. If your site publishes new content frequently or releases product updates on a regular cycle, twice per year is a better fit. The audit identifies whether conformance has held and flags any new issues introduced since the last evaluation. Accessible.org structures its accessibility audit services to support both initial and recurring engagements.
Can automated scans replace audits for ongoing maintenance?
No. Scans only flag approximately 25% of issues and cannot evaluate most WCAG success criteria. They are useful as a monitoring layer between audits but do not determine conformance on their own. A manual audit conducted by a qualified auditor is the only way to verify WCAG 2.1 AA or WCAG 2.2 AA conformance.
What is the biggest risk to conformance after remediation?
New content. Every page, image, video, form, or feature added to your site after remediation is a potential source of new issues. Without a process for reviewing new content against WCAG, conformance erodes steadily. Training and workflow integration are the most effective countermeasures.
Do we need an accessibility statement on our site?
An accessibility statement is not required by WCAG itself, but it is considered a best practice and may be required under certain regulations. It communicates your organization’s commitment, your target conformance level, and how users can report issues. Publishing one also signals to procurement teams and compliance reviewers that your organization takes accessibility seriously.
Maintaining WCAG conformance after remediation is a matter of building the right habits and systems. The work does not end when fixes are deployed. It shifts from intensive remediation to steady, manageable upkeep.
Contact Accessible.org for recurring audit services, training, and ongoing accessibility support.
