How to Build a Defensible Accessibility Audit & Remediation Report

Most organizations treat an accessibility audit as the finish line. They run the evaluation, get a list of issues, fix what they can, and file the report away. If a complaint surfaces later, they assume they can hand over the audit as proof they did the work.

That assumption is wrong, and it can backfire badly.

An audit report by itself is a list of failures. If those failures were never fixed and documented as fixed, the audit becomes evidence that your organization knew about the barriers and did nothing. That is the opposite of a legal defense.

What actually protects you is a defensible audit and remediation report: a structured record that shows exactly when issues were found, how they were prioritized, how they were fixed, and how those fixes were independently verified. It demonstrates that your organization runs an ongoing compliance program rather than occasional bursts of activity.

Here is what that documentation must contain to hold up in a lawsuit, a federal inquiry, or a procurement review.

Why This Matters Now

If you think you can defer this until the next budget cycle, look at the current landscape. And if you are not sure what this work should cost, How Much Should You Spend on Digital Accessibility? breaks down the numbers.

Under the DOJ’s ADA Title II rule, state and local governments, school districts, public universities, and municipal agencies must ensure their web content and mobile apps conform to WCAG 2.1 Level AA. The DOJ extended the compliance dates in April 2026: April 26, 2027 for public entities serving populations over 50,000, and April 26, 2028 for smaller entities. The extension is a reprieve, not a repeal. The requirement stands.

Healthcare organizations receiving federal financial assistance face the same WCAG 2.1 AA standard under HHS Section 504, with deadlines of May 11, 2027 for organizations with 15 or more employees and May 10, 2028 for smaller ones.

Private organizations face ADA Title III exposure. In 2025, plaintiffs filed 3,117 federal website accessibility lawsuits, a 27% increase over 2024. Total filings including state courts topped 5,000. Website cases now account for 36% of all federal ADA Title III filings, and 46% of federal cases targeted organizations that had already been sued before.

When a regulator, plaintiff’s attorney, or procurement officer asks you to prove your accessibility work, “we did an audit” is not an answer. “Here is our documented, verified remediation record” is.

Audit Report vs. Remediation Report: The Critical Difference

The two documents serve different purposes, and confusing them is where most organizations stumble.

An audit report tells you what is broken. It maps barriers to WCAG success criteria. It is diagnostic.

A remediation report proves what was fixed. It documents the fix work at the code level and the independent verification that each fix works. It is evidentiary.

You need both, connected. The remediation report bridges the gap between audit findings and actual engineering work. Every finding in the audit should be traceable through the remediation log to a verified resolution, or to a documented prioritization decision if the fix is scheduled for a later phase. Gaps in that chain are where legal exposure lives.

Follow the WCAG-EM 2.0 Framework

For your evaluation to be defensible, it needs to follow a standardized, repeatable methodology that a third party can reconstruct. That methodology exists, and it was just updated.

The W3C published WCAG-EM 2.0 (Website Accessibility Conformance Evaluation Methodology) on July 23, 2026, the first substantial update since 2014. The headline change: the methodology now applies to “digital products” rather than just websites, explicitly covering web applications, mobile apps, kiosk software, e-books, and documents including PDF and Word files. If your organization runs a mobile app or a document library, you can now evaluate it under the same citable framework as your website.

The five steps:

• Step 1: Define the evaluation scope. You cannot test every page on a large site. Define the boundaries of the audit, the conformance target (typically WCAG 2.1 AA), and the accessibility support baseline: the specific browsers and assistive technologies you will test against.
• Step 2: Explore the target product. Identify the common views, essential functionality (scheduling, enrollment, payment, service requests), the variety of sample types, and the technologies relied upon.
• Step 3: Select a representative sample set. Three parts: a structured sample that deliberately covers every view type and function, a random sample (10% of the structured set) that audits the evaluator’s judgment, and every view inside a complete process. A multi-step flow is only accessible if all of it is accessible.
• Step 4: Evaluate the sample. Test against WCAG success criteria, record passes and failures, and compare the structured and random samples against each other. If the random sample surfaces problems the structured sample missed, the sample was not representative and needs widening.
• Step 5: Report the findings. Document each step’s outcomes, the evaluation specifics, and a formal evaluation statement.

One point in WCAG-EM 2.0 deserves special attention for defensibility: the methodology is explicit that sampled evaluation supports an evaluation statement, not a full conformance claim. It states plainly that conformance claims cannot be made for an entire site based on evaluating a subset of pages alone. Any vendor promising “WCAG 2.1 AA certified” from a sampled audit is promising something the methodology it cites says it cannot deliver. A defensible report says exactly what was tested, how it was tested, and what the results support. Nothing more, nothing less. That precision is what makes it credible.

The Granular Remediation Log

The core evidentiary weight of the report lives in the remediation log. This is where abstract failures become specific engineering tasks, and where their resolution is proven. Every issue must be logged with these data points:

• Issue number and location. A unique identifier, plus the exact URL and page location of the barrier. Trackable from discovery through resolution.
• Issue description. A detailed narrative of the problem and its specific impact on users. Not “image failed 1.1.1” but “decorative hero image announced as ‘IMG_2847.jpg’ to screen reader users, disrupting navigation.”
• Applicable source code. The specific HTML, CSS, JavaScript, or ARIA snippet containing the failure. This proves the barrier was analyzed at the structural level, not guessed at from a scanner output.
• WCAG criteria mapping. The exact success criterion the code failed, such as 1.1.1 Non-text Content or 2.1.1 Keyboard. This ties technical failures to the legal standard.
• Users affected. The disability groups impacted: screen reader users, keyboard-only users, users with low vision, users with cognitive disabilities.
• Severity and impact. A prioritization matrix, typically High, Medium, Low, based on whether the barrier blocks a core function or creates friction. This shows the triage was systematic, not arbitrary.
• Remediation guidance. Prescriptive fix instructions for developers in standard engineering syntax. This removes guesswork and proves the fix followed recognized practice.
• Verification status. The most important column. A timestamped record that an independent expert re-tested the fix in production and confirmed it works. Who verified it, when, with which assistive technology, and what the result was.

That last point deserves its own section.

Verification: The Step That Makes It Defensible

Fixing an issue and confirming it is fixed are two different steps, and the second one is where defensibility is built.

The most reliable verification is always performed by someone other than the person who made the fix. Your developer ships the change; an independent accessibility expert re-tests it with the actual assistive technologies: NVDA, JAWS, VoiceOver, keyboard-only navigation. If the fix works, it gets logged with a timestamp and the tester’s qualifications. If it does not work, it goes back into the queue.

A report that lists problems and remediation guidance is a plan. A report with verified, timestamped resolutions is evidence. When an investigator asks what your organization did about a known barrier, the second document answers the question. The first one raises it.

Documenting PDF and Document Remediation

Web accessibility extends beyond HTML. Documents, particularly PDFs, are one of the largest and most frequently overlooked sources of liability, and 94% of public-facing PDFs fail basic accessibility standards.

A defensible document remediation report must validate conformance with ISO 14289-1, the PDF/UA (Universal Accessibility) standard, in addition to WCAG criteria. PDF/UA defines the technical requirements that make a PDF fully interoperable with assistive technologies like screen readers and braille displays.

The report should verify and document:

• A valid structure tree. The PDF must contain a logical hierarchy of semantic tags that defines the organization of the content. The report must state that these tags were manually verified or corrected, not just machine-generated.
• Logical reading order. The visual layout of a PDF often differs dramatically from the order in which a screen reader processes the content. The report must verify the content is logically sequenced so assistive technology reads the document sequentially rather than jumping across columns.
• Alternative text on all charts, graphs, and images. Descriptive text that conveys the visual information to blind users.
• Accessible form fields. Correct tab order and meaningful field labels on any interactive forms, so users are not trapped in the document.
• Accurate metadata. A defined title, author, and explicitly set document language so speech synthesizers use correct pronunciation.

Scanned PDFs carry the highest risk. A scan is a flat image of text, invisible to screen readers, and running simple OCR is not enough. The document must be fundamentally restructured and tagged, and the report must reflect that work.

For organizations with large document repositories, the report should maintain a living remediation log: initial automated scans of the document ecosystem, the manual remediation actions taken on high-risk files (applications, forms, notices), and the final accessibility status of each. It can also document strategic decisions to convert legacy PDFs into accessible HTML pages, which demonstrates a proactive, structural approach to risk rather than a one-time cleanup.

Documenting Multimedia Remediation

Video and audio content introduce their own documentation requirements, and a defensible report must cover both the content and the player.

• Audio-only content (podcasts, recorded meetings): verify a text transcript is present, easily accessible, accurately represents spoken content, identifies speakers, and notes relevant non-speech sounds.
• Video-only content (silent animations, demonstrations): verify visual events are narrated via an audio track or described in an accompanying text transcript.
• Synchronized multimedia (video with sound): verify synchronized captions for deaf and hard-of-hearing users, plus audio description of critical visual information during natural pauses for blind and low-vision users.

The report must also verify the media player itself. Player controls including play, pause, volume, and caption toggles must be fully operable by keyboard, and their states and roles must be announced to screen readers. This matters because automated testing tools routinely miss keyboard traps inside embedded third-party video players. Only manual verification catches them, and only documentation of that manual verification proves you did it.

How ClearPath Access Builds Defensible Documentation

Both of our service tiers are structured around the audit-remediate-verify loop that defensibility requires.

Managed Remediation is our end-to-end, expert-led service. We run the hybrid evaluation, combining automated scanning with deep manual testing by senior practitioners using screen readers and keyboard navigation. We fix the barriers, then independently verify each fix before it is marked resolved. Because the same team that fixes is not the team that verifies, the evidence chain stays clean.

Collaborative Remediation is our developer-integrated service for organizations with in-house development teams. We identify the failures and provide prescriptive remediation guidance; your developers ship the fixes; we independently re-test and verify them. Findings, fixes, and verification are centrally logged so every issue is traceable from discovery to confirmed resolution.

In both models, you end up with the same thing: a documented, timestamped, independently verified record of what was found, what was fixed, and proof that the fixes work. That is the document you hand to legal counsel, the one you show a regulator, and the one that demonstrates your organization’s ongoing commitment rather than a one-time scramble.