To simplify an accessibility project, define the scope upfront, conduct a (manual) audit on a representative sample of pages or screens, prioritize issues by Risk Factor or User Impact, remediate in focused sprints, then validate fixes before moving on. The work moves faster when scope is tight, ownership is clear, and progress is tracked in one place. Most delays come from unclear inputs at the start, not the technical fixes themselves. A simplified project treats the audit report as the single source of truth and routes every issue from identification to validation without detours.
| Phase | What keeps it moving |
|---|---|
| Scope | Inventory digital assets, choose a representative sample, lock the WCAG version (2.1 AA or 2.2 AA). |
| Audit | Conduct a (manual) audit. Scans only flag approximately 25% of issues and cannot determine conformance. |
| Prioritize | Apply Risk Factor or User Impact prioritization formulas to sequence remediation. |
| Remediate | Assign issues to developers and designers in focused sprints with clear acceptance criteria. |
| Validate | Auditor reviews fixes. Failed validations return to the queue with notes. |
| Maintain | Train the team, update documentation, and re-audit after major releases. |
Start with a tight scope
The fastest projects start with the cleanest inputs. Take inventory of every digital asset that falls under the project: marketing site, web app, mobile app, PDFs, and any third-party tools embedded in the experience.
Then narrow the audit to a representative sample. A 30-page sample on a 5,000-page site covers the patterns that repeat across templates without auditing every URL. The same logic applies to screens in a web app or mobile app.
Lock the standard before the audit begins. WCAG 2.1 AA is still the most requested. WCAG 2.2 AA is gaining ground, especially in procurement and public sector work.
What slows accessibility projects down?
Three things, almost every time. Unclear scope, scattered tracking, and treating the audit as the finish line instead of the starting line.
Unclear scope means the team is still debating which pages count two weeks into remediation. Scattered tracking means issues live in spreadsheets, Jira tickets, Slack threads, and email all at once. Treating the audit as the finish line means the report gets delivered, celebrated, and then sits while developers wait for direction.
Simplified projects centralize the issue list, route every fix through one workflow, and keep the auditor available for validation as fixes ship.
Conduct a (manual) audit, not a scan
Automated checkers detect approximately 25% of issues. They cannot evaluate context, alternative text quality, keyboard logic, focus order, or whether an interaction works for a screen reader user. A scan score of 100 is not WCAG conformance.
A (manual) accessibility audit is the only way to determine WCAG conformance. The auditor identifies issues at the success criterion level, documents how to reproduce them, and provides remediation guidance the development team can act on.
The deeper a project goes into a thorough audit upfront, the less rework happens later. Skipping the audit to save time almost always costs more time downstream.
Prioritize before remediating
An audit report can list dozens or hundreds of issues. Without prioritization, teams either start at the top of the list or pick whatever looks easiest. Both approaches stall.
Apply Risk Factor or User Impact prioritization formulas. Risk Factor weights the legal exposure of an issue. User Impact weights how much an issue blocks people who rely on assistive technology. Most teams use a blend.
The goal is to fix the issues that move the conformance needle and reduce risk first, then work down the list in batches.
Move remediation through focused sprints
Remediation works best when it lives inside the development cycle, not next to it. Group issues by component, by template, or by page section so a developer can fix a category of issue in one focused block of time.
Each issue should have a clear owner, a target sprint, and acceptance criteria tied back to the WCAG success criterion. Vague tickets create vague fixes.
Validate fixes as they ship
Validation is where projects either land or drift. Once a developer marks an issue as fixed, the auditor reviews it against the original finding. If the fix passes, it closes. If not, it returns to the queue with notes.
Running validation continuously, rather than batching it for the end, keeps the project moving. It also prevents the all-too-common scenario where a team thinks they are done, only to learn that half the fixes did not address the underlying issue.
Centralize tracking
One source of truth makes everything faster. Whether that is a project management platform built for accessibility or a well-structured spreadsheet, the team needs to see the same issue list, status, owner, and notes.
The Accessibility Tracker Platform was built for this work, with audit data, prioritization, status tracking, validation, and progress reporting in one place. Accessible.org Labs is also actively researching how AI can support remediation guidance and reporting inside the platform without overstating what AI can do.
Maintain conformance after launch
Conformance is a state, not a milestone. New code, new content, and new third-party integrations introduce new issues. A simplified project plans for this from the start.
Train designers and developers on the success criteria most relevant to their work. Add accessibility review to the definition of done. Re-audit after major releases or at a regular cadence, whichever comes first.
How long does a simplified accessibility project take?
It depends on the size of the asset and the volume of issues, but a typical mid-sized website project moves through audit, prioritization, remediation, and validation in 8 to 16 weeks. Larger web apps and mobile apps take longer. The biggest variable is remediation capacity on the development side.
Can AI speed up the work?
AI can help, but not in the way some vendors claim. Real AI applications support the people doing the work: faster triage of audit findings, clearer remediation guidance, and quicker progress reporting. AI cannot determine WCAG conformance and cannot replace a human auditor.
Do we need to audit every page?
No. A representative sample identifies the patterns that repeat across templates. Once those patterns are fixed at the template or component level, the fix carries across every instance.
What is the fastest path to a VPAT or ACR?
Conduct the audit, remediate the highest-impact issues, and document the current state in the ACR. The ACR reflects conformance at a point in time. It can be updated after future remediation cycles.
Simplifying the process is mostly about removing friction between phases. The technical work is rarely the bottleneck. Clear scope, one tracking system, and continuous validation do most of the heavy lifting.
To plan or accelerate your accessibility project, Contact Accessible.org.
