Why remediation programs fail
Organizations spend $10,000 to $25,000 on an accessibility audit, receive a 60-page report with 300 findings, and then nothing happens. The report gets forwarded to a development team that is already behind on feature work. Findings sit in a shared drive. Six months later, a demand letter arrives and the same issues are still live on the site.
The problem is not awareness. It is operational. Remediation needs a program — with ownership, process, tooling, and accountability — the same way security vulnerabilities and production incidents need one.
Step 1: Assign a program owner
Every successful remediation program has a single accountable person. This does not need to be a full-time accessibility specialist. It can be a product manager, QA lead, or compliance officer who takes ownership of:
- Maintaining the remediation backlog
- Setting priorities and SLAs
- Reporting progress to leadership
- Coordinating between design, development, content, and legal teams
Without a named owner, accessibility becomes everyone's job and therefore nobody's job.
Step 2: Categorize findings by severity
Not all accessibility issues carry equal weight. Use a three-tier severity model:
- Critical (P0): Complete barriers to access. Keyboard traps, missing form labels on login or checkout, no alt text on functional images, inaccessible navigation. These block users entirely and are the issues most cited in lawsuits. SLA: fix within 14 days.
- Major (P1): Significant usability barriers. Poor color contrast on body text, missing heading structure, videos without captions, inconsistent focus indicators. These degrade the experience substantially. SLA: fix within 30 days.
- Minor (P2): Best practice violations and edge cases. Decorative images with non-empty alt text, minor contrast issues on disabled elements, redundant ARIA attributes. These should be fixed but do not block users. SLA: fix within 90 days.
Step 3: Integrate into existing workflows
Accessibility findings should live in the same system your team already uses for bug tracking and feature work. If your team uses Jira, findings go into Jira. If you use Linear, they go into Linear. Do not maintain a separate spreadsheet or PDF that developers have to check independently.
Each finding should include:
- The specific WCAG success criterion violated
- The affected page URL and element selector
- A screenshot or screen recording showing the issue
- The expected behavior per WCAG guidance
- A suggested code fix when possible
Step 4: Build accessibility into the development lifecycle
Remediating existing issues is necessary but insufficient. You need to prevent new issues from being introduced:
- Design review: Check wireframes and mockups for contrast, touch target size, focus order, and text alternatives before development begins.
- Component libraries: Build accessible components once and reuse them. An accessible date picker used everywhere is better than fixing inaccessible date pickers on 40 pages.
- Automated testing: Add axe-core or similar tools to your CI/CD pipeline. Block deployments that introduce critical accessibility violations.
- Code review checklist: Add accessibility criteria to your pull request template. Reviewers should check for labels, keyboard handlers, ARIA usage, and semantic HTML.
- QA testing: Include keyboard navigation and screen reader checks in your QA process for every feature.
Step 5: Train your team
Most accessibility issues are introduced by well-meaning developers and content creators who simply do not know the requirements. Invest in practical training:
- For developers: Semantic HTML, ARIA patterns, keyboard interaction models, and how to test with a screen reader.
- For designers: Color contrast requirements, focus indicator design, touch target sizing, and content hierarchy.
- For content creators: Writing alt text, structuring headings, creating accessible PDFs, and captioning video.
- For QA: Testing with keyboard only, using browser accessibility inspectors, and validating screen reader output.
Step 6: Measure and report
Track metrics that reflect real progress:
- Open findings by severity: The primary health metric. Critical count should trend toward zero.
- Mean time to remediation: How long findings stay open. Compare against your SLAs.
- Regression rate: How many new issues are introduced per sprint. A declining rate means your prevention efforts are working.
- Pages scanned vs total pages: Coverage metric. You cannot fix what you have not tested.
Report monthly to leadership with a one-page summary: current state, trend direction, top risks, and resource needs. Executive visibility keeps the program funded and prioritized.
Step 7: Plan for the long term
Accessibility is not a project with a finish date. It is an ongoing operational discipline. Budget for:
- Annual comprehensive audits to validate your automated testing
- Quarterly manual spot checks of key user flows
- Ongoing tool licensing for automated scanning
- Staff training refreshers as WCAG standards evolve
- Content remediation for new materials (PDFs, videos, social media)
Bottom line
A remediation program that works treats accessibility like security: owned, measured, integrated into workflows, and continuously monitored. The organizations that avoid ADA lawsuits are not the ones with the biggest budgets — they are the ones with the most disciplined processes.