What a Court-Admissible Compliance Log Should Include

what a court-admissible compliance log should include

Companies that deal with website accessibility under the Americans with Disabilities Act often hear the same advice after receiving a demand letter: document everything.

That advice usually leads to something called a compliance log.

A compliance log is a running record of accessibility work performed on a website or digital product. It tracks when issues were discovered, how they were fixed, and what testing happened afterward.

This type of documentation matters when accessibility disputes reach legal review. Courts don’t evaluate accessibility based on marketing language or accessibility statements. They look at evidence. Logs, audit reports, remediation tickets, and testing records show whether a company actively worked on accessibility or ignored it.

A compliance log does not prevent lawsuits. It does not prove full accessibility either. But when properly maintained, it shows a pattern of maintenance and remediation.

That pattern can become relevant in litigation, settlement discussions, or regulatory inquiries.

what a compliance log actually is

A compliance log is a chronological record of accessibility work performed on a website.

Think of it as an engineering journal for accessibility.

Every entry documents a specific event:

an accessibility audit
a remediation fix
a code deployment addressing accessibility issues
a testing session with assistive technology
a user complaint related to accessibility

The log captures the details that prove the work happened.

Typical entries include:

date of activity
description of the issue
WCAG success criterion involved
location of the issue on the site
remediation steps taken
verification testing performed

Over time the log becomes a timeline of accessibility efforts.

If litigation occurs under the Americans with Disabilities Act, attorneys reviewing the case often request this documentation.

why courts care about documentation

Courts dealing with accessibility cases evaluate evidence.

In website accessibility disputes, the technical standard most often referenced is the Web Content Accessibility Guidelines (WCAG).

These guidelines were developed by the World Wide Web Consortium and include dozens of testable success criteria covering topics such as keyboard navigation, screen reader compatibility, and form accessibility.

When a case reaches court, plaintiffs usually present evidence showing accessibility barriers on the site.

Defendants respond with documentation showing their accessibility practices.

Judges look at patterns.

Did the company perform accessibility testing?

Did it respond to reported accessibility barriers?

Did it remediate issues once identified?

Compliance logs answer those questions.

the difference between a compliance log and an accessibility audit

Many companies already have accessibility audit reports.

Audits and compliance logs serve different purposes.

An accessibility audit is a snapshot. It evaluates the website against WCAG criteria at a specific point in time.

A compliance log records ongoing work after the audit.

For example:

An audit may identify 45 accessibility issues across the website.

The compliance log records how each issue was addressed.

Example entry:

Date: March 12, 2024
Issue: Missing alt text on product images
WCAG reference: WCAG 1.1.1 Non-text Content
Action taken: Added descriptive alt text to 312 product images
Verification: Tested with NVDA screen reader on Windows 11

The log shows the remediation process step by step.

the minimum information a compliance log should include

A court-admissible compliance log must contain enough detail to verify that accessibility work occurred.

At minimum, each entry should include:

date of the activity
person or team responsible
description of the issue
WCAG success criterion involved
location of the issue
remediation steps taken
verification method

Without these details, the log becomes difficult to evaluate.

Entries that simply say “accessibility fix completed” are not useful in legal review.

Courts look for traceable documentation.

dates and timestamps

Every entry must include the date when the activity occurred.

This seems obvious but many internal logs omit timestamps.

Dates establish the timeline of accessibility efforts.

For example:

January 15, 2024 – accessibility audit completed
February 2, 2024 – remediation work started
March 5, 2024 – keyboard navigation fixes deployed

Without dates, the record cannot show whether accessibility work happened before or after complaints were filed.

the issue description

Each entry should clearly describe the accessibility problem that was discovered.

Vague descriptions weaken the record.

Compare these two examples:

Weak entry:

“Accessibility issue fixed.”

Strong entry:

“Dropdown navigation menu could not be opened using keyboard input. Users relying on keyboard navigation could not access submenus.”

The second description explains the barrier in practical terms.

the wcag success criterion involved

Accessibility issues should be tied to the relevant WCAG success criterion.

WCAG includes dozens of criteria covering topics such as:

non-text content alternatives
keyboard accessibility
focus order
color contrast
error identification

Example entry:

Issue: Form input fields missing labels
WCAG reference: WCAG 3.3.2 Labels or Instructions

This reference shows that the remediation work was tied to recognized accessibility standards.

the location of the issue

The log should identify where the issue occurred.

Examples include:

URL of the page
template name
interface component
application module

Example:

Location: checkout page – billing information form

Large websites often contain thousands of pages. Without location details it becomes difficult to verify whether the issue was fixed across the site.

remediation steps taken

The log must describe how the issue was resolved.

Examples:

Added alt text to image elements
Updated button markup to include ARIA labels
Adjusted CSS color contrast values
Modified JavaScript menu to allow keyboard navigation

These descriptions should be specific enough that developers can understand the change.

verification testing

After remediation, accessibility fixes should be verified.

Verification often includes manual testing with assistive technologies such as screen readers.

Common testing tools include NVDA, JAWS, or VoiceOver.

Example entry:

Verification: tested with NVDA screen reader and keyboard-only navigation. Dropdown menu accessible using Tab and Arrow keys.

Verification confirms that remediation actually resolved the issue.

version numbers and deployment records

Many companies include version numbers or deployment references in their compliance logs.

Example entry:

Fix deployed in release version 4.3.2 on April 11, 2024.

Version tracking helps correlate accessibility fixes with development releases.

This can be useful if later updates introduce regressions.

documenting accessibility audits

Compliance logs should also include entries for full accessibility audits.

Example entry:

Date: September 18, 2023
Activity: WCAG 2.1 Level AA accessibility audit conducted
Scope: 12 page templates tested
Auditor: accessibility consultant team
Findings: 52 accessibility issues identified

The log should reference the full audit report.

This entry marks the starting point for remediation work.

documenting user accessibility complaints

Accessibility complaints should also appear in the compliance log.

Example entry:

Date: May 2, 2024
Report: blind user reported inaccessible dropdown menu on appointment booking page
Action: issue reproduced using keyboard navigation
Resolution: JavaScript menu rewritten to support keyboard interaction

Recording complaints demonstrates that the organization responded to user feedback.

Courts often consider how companies respond to reported accessibility barriers.

a real example where documentation mattered

In 2021 a regional healthcare provider received a website accessibility lawsuit alleging that blind users could not schedule appointments online.

The complaint referenced failures involving unlabeled form fields and keyboard navigation barriers.

During discovery, the company produced two types of records:

an accessibility audit conducted six months earlier
a compliance log documenting remediation work

The log included detailed entries showing that developers fixed multiple accessibility issues after the audit.

Some issues remained unresolved at the time of the lawsuit.

Still, the documentation showed that the organization had been actively working on accessibility rather than ignoring it.

The case settled later that year.

Settlement details were not public.

The documentation did not eliminate the lawsuit. It provided context.

why informal notes are not enough

Some companies attempt to track accessibility fixes using internal chat messages or scattered development tickets.

That documentation is often incomplete.

Chat logs do not create a clear accessibility timeline. Development tickets may not reference WCAG criteria or verification testing.

A dedicated compliance log consolidates this information into a structured record.

That structure matters when documentation is reviewed outside the organization.

common mistakes in compliance logs

Several mistakes appear frequently when companies attempt to maintain accessibility documentation.

Missing dates

Entries without timestamps weaken the timeline.

Incomplete descriptions

Logs that say “accessibility issue fixed” without describing the issue provide little value.

No verification records

Remediation should be followed by testing documentation.

No WCAG references

Without referencing WCAG success criteria, it becomes harder to demonstrate that remediation aligned with recognized accessibility standards.

Scattered records

Accessibility work documented across email threads, spreadsheets, and issue trackers is difficult to review later.

how compliance logs are maintained in practice

Many companies maintain compliance logs using simple tools.

Common formats include:

spreadsheets
internal compliance dashboards
project management systems
version-controlled documentation

The format matters less than consistency.

The key requirement is that entries are chronological, detailed, and preserved.

Logs should not be edited retroactively without clear revision history.

the relationship between compliance logs and accessibility statements

Accessibility statements describe accessibility practices to the public.

Compliance logs document those practices internally.

If an accessibility statement claims that the company regularly audits and improves accessibility, the compliance log should show that work.

Discrepancies between public claims and internal documentation can create credibility problems during legal review.

why compliance logs need long-term retention

Accessibility lawsuits sometimes reference events that occurred years earlier.

Companies should retain accessibility documentation for extended periods.

Many organizations keep compliance logs for at least five years.

Longer retention periods are common for companies operating in regulated industries such as healthcare or financial services.

Retention policies vary.

The goal is simple: maintain a record of accessibility work that reflects the life cycle of the website.

accessibility maintenance as a documented process

Accessibility is not a one-time project.

Websites change continuously. New content, design updates, and feature releases introduce new accessibility issues.

Compliance logs capture the maintenance process.

Instead of treating accessibility as a static certification, the log shows ongoing work:

audits
remediation
testing
user feedback
subsequent fixes

When accessibility questions arise, the documentation shows how the organization handled those issues over time.

That record often becomes the most concrete evidence of accessibility work.