how to document a good faith effort for ADA website accessibility
Businesses often start thinking about website accessibility after receiving a demand letter or legal complaint. By that point, the discussion usually shifts to proof. Not just whether the site is accessible, but whether the business made a genuine attempt to address accessibility barriers.
Courts reviewing ADA website cases sometimes look at the defendant’s actions before and after a complaint was filed. Documentation becomes part of that discussion. Emails, audit reports, remediation tickets, accessibility policies, and internal meeting notes can show whether a company took accessibility seriously or ignored it.
A “good faith effort” is not defined in a single statute. The Americans with Disabilities Act does not include a detailed rulebook for websites. But patterns appear in litigation and settlement agreements. Businesses that document accessibility work — audits, fixes, training — are often able to show they attempted compliance.
Documentation does not guarantee dismissal of a lawsuit. Some cases move forward even when remediation work is underway. But records of accessibility work frequently shape negotiations and settlement terms.
The difference between a company that ignored accessibility and one that worked on it often comes down to documentation.
what courts mean by “good faith effort”
ADA Title III requires businesses open to the public to provide equal access to goods and services. Websites are not explicitly described in the original 1990 law, but courts increasingly treat them as extensions of physical businesses.
When an accessibility case reaches court, the judge typically focuses on whether barriers prevented a disabled user from accessing the site. But the defendant’s response also matters.
If a company receives a complaint and immediately starts fixing accessibility barriers, that behavior may affect how the case proceeds.
Some courts refer to this as acting in good faith. The concept appears in multiple accessibility cases and settlement discussions.
A business that demonstrates a documented remediation process can argue that it is actively addressing the issue rather than ignoring it.
Documentation becomes the evidence.
the accessibility audit as the first record
Most accessibility work starts with an audit.
An accessibility audit examines a website for barriers that affect users with disabilities. Audits usually include automated scanning and manual testing with assistive technologies.
Automated tools such as WAVE, Axe, or Lighthouse detect common technical problems. Missing alt text, color contrast failures, and empty links appear quickly in these reports.
Automated scans do not capture everything. Accessibility professionals often say automated testing detects roughly 30 percent of accessibility problems.
Manual testing fills the gap.
During manual testing, an auditor may navigate the site using screen readers such as NVDA or JAWS. Keyboard navigation testing is also common.
The audit report becomes the first major piece of documentation.
A typical report may include:
Screenshots of accessibility failures.
WCAG references tied to each issue.
Descriptions of how users encounter the barrier.
Recommended remediation steps.
Many audits run dozens of pages long.
A PDF audit report dated before or shortly after a complaint shows that the business started accessibility work.
That timestamp matters.
documenting remediation work
An audit identifies accessibility barriers. Remediation fixes them.
Developers usually track remediation tasks using ticket systems such as Jira, GitHub issues, or project management tools. Each ticket describes the accessibility problem and the fix applied.
Those records become evidence that accessibility work actually happened.
For example, a developer ticket might read:
“Fix missing alt text on product images – 214 images updated across catalog pages. Completed May 14, 2024.”
Another might document navigation improvements:
“Keyboard focus added to dropdown menu elements. Tested with NVDA screen reader.”
These records show progress over time.
Without them, a company may struggle to prove that remediation occurred.
keeping before-and-after evidence
Screenshots are simple but useful documentation.
Accessibility testers often capture screenshots showing barriers before remediation.
For example:
A form field without a label.
A button that reads only “click here.”
A color contrast failure flagged by an accessibility tool.
After remediation, the tester captures another screenshot showing the corrected element.
This before-and-after evidence shows that a specific accessibility barrier existed and was fixed.
Lawyers frequently include this type of documentation in settlement negotiations.
It demonstrates measurable improvement.
maintaining an accessibility statement
An accessibility statement is a public document explaining the company’s approach to accessibility.
Many organizations publish these statements on their websites.
A typical statement may include:
The accessibility standard the company follows, often WCAG 2.1 Level AA.
The date of the most recent accessibility review.
Contact information for reporting accessibility barriers.
An accessibility statement alone does not prove compliance.
But it becomes part of the documentation trail.
If a complaint arises, the company can show that accessibility policies were publicly acknowledged.
Some statements also include revision histories.
Those timestamps matter.
They show that accessibility was addressed before litigation began.
keeping records of accessibility training
Accessibility is not only a technical issue. Staff training also appears in some settlement agreements.
Companies may train developers, designers, and content editors on accessibility guidelines.
Training documentation can include:
Attendance records.
Training slides or materials.
Instructor names and dates.
For example, a company might record that its web development team attended a WCAG training session in March 2024.
If accessibility errors later appear, the company can still show that it invested in education.
Courts do not treat training as a defense to accessibility barriers. But documentation shows the company attempted to address the issue systematically.
accessibility testing logs
Regular testing creates another layer of documentation.
Some companies run quarterly or annual accessibility reviews.
Testing logs may include:
Testing dates.
Tools used.
Assistive technologies tested.
Accessibility issues discovered.
Accessibility issues resolved.
For example, a log entry might read:
“Accessibility review conducted September 10, 2024. Automated scan and manual NVDA testing. 17 issues identified, primarily missing alt text and color contrast failures.”
The log can later show whether those issues were resolved.
Repeated testing records demonstrate ongoing accessibility work rather than a single one-time fix.
the role of WCAG documentation
Most ADA website cases reference the Web Content Accessibility Guidelines.
WCAG is not written directly into the ADA statute, but courts frequently use it as the technical benchmark for accessibility.
When a company documents remediation work, referencing WCAG criteria strengthens the record.
For example, remediation notes might include statements like:
“Fixed WCAG 1.1.1 failure – added alt text to decorative and informative images.”
“Corrected WCAG 2.4.7 issue – visible keyboard focus added to navigation links.”
These references connect the technical work to established accessibility standards.
Documentation tied to WCAG criteria shows that remediation followed recognized guidelines.
accessibility policies inside the organization
Some companies adopt internal accessibility policies.
These policies describe how accessibility will be handled in design, development, and content publishing.
A policy might include requirements such as:
All images must include alt text.
Videos must include captions.
Developers must test new features using keyboard navigation.
The policy may also describe who is responsible for accessibility oversight.
An accessibility policy document dated before litigation can support a good faith argument.
It shows that accessibility was addressed at an organizational level rather than ignored.
responding to accessibility complaints
When a user reports an accessibility problem, the response becomes part of the documentation.
Companies sometimes receive accessibility complaints through email or contact forms.
Keeping records of those messages and responses can demonstrate responsiveness.
For example, an email exchange might show that a blind user reported an inaccessible form and the company responded within two days.
If the issue was fixed, the company can document the resolution.
These records show that accessibility concerns were addressed rather than dismissed.
an example from a small business remediation effort
A small dental practice in Illinois faced an accessibility complaint in 2023. The complaint described barriers on the practice’s website appointment form.
The form lacked labels for several input fields. Screen readers announced the fields simply as “edit text.”
The dentist hired a web developer to conduct an accessibility audit. The audit report identified the form labeling issue and several other problems, including missing alt text on staff photos.
The developer documented the remediation work over a two-week period.
The documentation included:
The original audit report.
GitHub commits showing code changes.
Screenshots of the corrected form labels.
Testing notes from NVDA screen reader checks.
The case settled before trial. The documentation showed that remediation was underway.
The dentist still paid a settlement amount and legal fees, but the accessibility improvements remained in place.
limitations of documenting a good faith effort
Documentation does not eliminate legal risk.
A website can still violate accessibility standards even if remediation work has started.
Some plaintiffs file lawsuits despite ongoing accessibility improvements.
Courts generally focus on whether barriers existed when the plaintiff attempted to use the website.
If the barrier existed at that moment, documentation of future fixes does not erase it.
The records still matter during settlement discussions. But they do not automatically stop litigation.
the problem with undocumented fixes
Businesses sometimes fix accessibility problems quietly.
A developer may update alt text or adjust color contrast without recording the change.
Months later, if a complaint appears, the company cannot easily prove when the fix occurred.
Without documentation, remediation work may appear to have happened only after the lawsuit began.
That timeline weakens the argument that accessibility was addressed earlier.
Simple records prevent this problem.
Even a short developer note or ticket history creates a timestamp.
why overlays rarely count as a good faith effort
Some companies install accessibility overlays after receiving complaints.
An overlay is a script that adds an accessibility widget to the website.
The widget may allow users to change text size, contrast, or spacing.
Overlay vendors sometimes claim these tools create immediate ADA compliance.
Accessibility professionals and disability advocates have criticized those claims.
In 2021, more than 400 accessibility specialists and disability advocates signed a public letter opposing overlays as compliance solutions. The letter stated that overlays do not correct the underlying code errors that create accessibility barriers.
Because overlays do not modify the site’s HTML structure, accessibility problems often remain.
For example, a product image without alt text remains unlabeled even if an overlay is installed.
Courts reviewing accessibility complaints typically focus on whether the barrier still exists.
Installing an overlay without fixing the underlying issues rarely counts as remediation.
what documentation often looks like in settlement negotiations
When ADA website cases reach settlement discussions, attorneys often exchange documentation.
Defendants may provide:
Accessibility audit reports.
Developer remediation logs.
Accessibility policy documents.
Training records.
Testing logs.
These documents show the steps taken to address accessibility.
Settlement agreements sometimes require continued documentation.
For example, an agreement may require annual accessibility testing for several years.
The documentation then becomes part of compliance monitoring.
accessibility as an ongoing process
Websites change frequently. New content, design updates, and software changes can introduce accessibility barriers.
Documentation therefore needs to continue after remediation.
Many companies schedule periodic accessibility reviews.
A typical schedule may include quarterly automated scans and annual manual testing.
These reviews create ongoing records showing that accessibility remains part of the development process.
Without continued documentation, accessibility improvements may fade over time.
how businesses structure accessibility documentation
Accessibility documentation often ends up in several different places.
Audit reports may be stored in internal document systems.
Developer fixes may appear in version control logs.
Training records may exist in HR systems.
Testing reports may be stored in accessibility software dashboards.
The exact structure varies by company.
The key issue is that records exist and are dated.
Those timestamps show when accessibility work occurred.
what actually demonstrates a good faith effort
A good faith effort in website accessibility usually leaves a visible record.
The record may include audit reports, remediation logs, accessibility policies, training materials, testing results, and user complaint responses.
Each document shows a step taken toward accessibility.
Courts evaluating ADA website cases still focus on whether barriers exist. Documentation does not replace accessibility work.
But it shows that the company attempted to address the problem rather than ignore it.
That record often shapes how accessibility disputes are resolved.

Comments (0)
No comments yet.