After an accessibility audit, the work shifts from evaluation to action. The audit report identifies every WCAG issue found across the scoped pages or screens, and the next phase centers on reviewing those findings, prioritizing fixes, remediating issues, and validating the work. Done well, this sequence moves a website or app toward WCAG 2.1 AA or 2.2 AA conformance and produces the documentation needed for legal defense, procurement, or an ACR. The audit itself is a snapshot. What follows determines whether that snapshot turns into measurable progress.
| Phase | What It Covers |
|---|---|
| Report Review | Read every issue, severity rating, and recommended fix with the team that will do the work. |
| Prioritization | Order issues using Risk Factor or User Impact prioritization formulas. |
| Remediation | Developers and designers apply fixes to code, content, and design assets. |
| Validation | The auditor reviews each fix and confirms whether it resolves the issue. |
| Documentation | Accessibility statement, conformance claim, or ACR captures the result. |
Reviewing the Audit Report
The first step is reading the report carefully with the people who will act on it. That usually includes a project lead, a developer or two, and a designer if visual issues are present.
A good report lists each issue with the WCAG success criterion it relates to, the location, the severity, and a recommended fix. Reading through it as a team surfaces questions early and prevents misinterpretation later.
Some issues will be obvious. Others involve patterns that repeat across templates or components, which means one fix can resolve dozens of instances.
How Do You Prioritize Issues After an Audit?
Not every issue carries the same weight. A missing form label affects every user filling out that form. A decorative image with a minor contrast issue does not.
Accessible.org uses Risk Factor or User Impact prioritization formulas to order issues. Risk Factor weighs the legal and business exposure of each issue. User Impact weighs how much the issue affects people using assistive technology.
Most teams work top-down: critical and high-severity issues first, medium next, low last. The order matters because remediation budgets and timelines are finite, and fixing the issues that affect the most users on the most critical pages pays off fastest.
Remediation
Remediation is where developers and designers apply the fixes. Code changes, content updates, design adjustments, and template revisions all happen in this phase.
The recommended fixes in the audit report give the team a starting point, but real remediation often requires judgment. A recommendation might say “add an accessible name to this control,” and the developer has to decide which method fits the existing pattern.
Tracking matters here. Without a system to map issues to status (open, in progress, fixed, validated), things lose freshness fast.
Validation
After fixes are applied, the auditor returns to confirm the work. This is validation, and it is the only way to know a fix actually resolved the issue.
Some fixes look right but introduce new issues. A developer might add an aria-label that conflicts with visible text, or a color change might pass contrast on one component while breaking it on another. Validation catches these.
Validation produces an updated record showing which issues are resolved and which remain. That record becomes the foundation for any conformance claim or ACR that follows.
Documentation and Conformance Claims
Once validation is complete, the team can document the result. Three documents commonly come out of this phase:
Accessibility statement: A public-facing page describing the site’s accessibility status, the standard targeted, and how to report issues.
WCAG conformance claim: A formal statement that the site or app conforms to WCAG 2.1 AA or 2.2 AA, often with a statement of partial conformance for any remaining issues.
ACR: An Accessibility Conformance Report based on a VPAT, used in procurement and government contracts.
The right document depends on the situation. A SaaS company selling to enterprise buyers will likely need an ACR. A small business focused on ADA risk reduction may need an accessibility statement and a conformance claim.
Ongoing Monitoring
Conformance is not a one-time milestone. Websites and apps change constantly, and new content can introduce new issues.
Teams that take accessibility seriously build monitoring into their workflow. That includes automated scans on a recurring basis (scans only flag approximately 25% of issues), training for content authors and developers, and follow-up audits when significant changes ship.
The audit established the baseline. Monitoring keeps the baseline from slipping.
Frequently Asked Questions
How long does the work after an audit usually take?
It depends on the issue count and the team’s capacity. A small website with 30 issues can be remediated and validated in a few weeks. A large web app with hundreds of issues across multiple templates can take several months. Prioritization helps the team move on the most important issues first regardless of total timeline.
Do you need the same auditor to validate fixes?
It is strongly recommended. The auditor who identified the issues understands the context, the user flows evaluated, and the assistive technology behavior observed. A different auditor would have to re-learn the product before validating, which adds cost and risk of inconsistency.
What if some issues cannot be fixed right away?
That is common. A statement of partial conformance can document which issues remain and why, with a plan to address them in a future release. This is honest, defensible, and far better than claiming full conformance when it is not accurate.
Can scans replace a follow-up audit?
No. Scans flag a fraction of issues and cannot determine WCAG conformance. They are useful for catching regressions on basic items between audits, but a manual evaluation remains the only way to verify conformance.
The phase after an audit is where conformance is actually built. The report points the way, and the work that follows turns findings into a more accessible product.
Ready to move from audit to action? Contact Accessible.org to discuss your remediation and validation needs.
