The short answer
After receiving an ADA website complaint or demand letter, preserve the notice, consult qualified counsel about legal obligations and deadlines, and build a separate technical record of the website barriers being evaluated. A scan can support investigation, but it does not decide whether an allegation is legally valid or whether a complaint has been resolved.
ADAFix provides technical accessibility support, not legal representation. The purpose of this checklist is to make findings, repairs, verification, and remaining limitations understandable to the business and its attorney. It is not a legal response template or a guarantee against litigation.
Preserve the original notice and the relevant context
Keep the original document and how it was received. Record the delivery date, referenced URLs, alleged barriers, and any stated deadlines. Do not assume a website update changes a response deadline. Give the notice to counsel rather than relying on a technical service to interpret it.
Where lawful and practical, preserve the relevant website version and deployment history. Avoid deleting evidence or rewriting the alleged events as though a present-day scan can show exactly what a visitor experienced earlier. If a site has changed, say so explicitly.
Protect personal and sensitive information. Technical screenshots and shared reports should contain only the information required to explain the finding. Access controls and private document storage remain important even when the underlying website is public.
Define the technical assessment before running tests
List the exact URLs, page states, user accounts, devices, and customer tasks included. A complaint about a restaurant reservation should not be answered with only a homepage scan. A retail checkout allegation requires attention to product selection, cart behavior, validation, payment transitions, and confirmation within the authorized scope.
Separate your own components from embedded services. Identify pages that require authentication, third-party providers, downloadable documents, or interactions the scanner does not exercise. Those boundaries should remain visible in the final report.
Assessment item | What to record | What not to infer |
|---|---|---|
Public-page scan | URL, date, rules and rendered state | That every page or interaction was tested |
Manual keyboard task | Steps, controls, outcome and limitations | That all assistive technologies behave identically |
Screen-reader evaluation | Tool, environment and evaluated task | Complete conformance from one task |
Document or provider review | The responsible system and review scope | That a website-source change repaired the external system |
Map allegations to findings without inventing certainty
Keep the customer's supplied allegation separate from the technician's observation. For each allegation, record the affected page or task, the method used, and whether the issue was reproduced in that test.
Useful statuses include reproduced, not reproduced in the present test, changed since the notice, and requiring manual review. 'Not reproduced' is not the same as 'never existed.' 'Needs review' should not become 'fixed' because a scanner reports no violation.
If an allegation is too broad to map safely, describe the uncertainty. Do not silently substitute an easier barrier and present that repair as resolving the original complaint.
Prioritize task-blocking barriers and responsible owners
A customer unable to complete a booking or purchase can face a more serious practical barrier than a decorative defect. Prioritization should consider the user's task, impact, and scope, not only an automated severity label.
Assign an owner to each repair: content editor, theme developer, application team, document specialist, or external provider. If a component is outside your control, keep the provider request and dependency in the record. A temporary assistance route may help customers, but it should not be described as proof that the website itself is repaired.
Review source changes before deployment. Confirm labels and alternative text with the business when meaning matters. Preserve the original version, proposed change, accepted change, and reversal path where applicable.
Verify deployment and then repeat the affected task
A proposed patch is not a deployed repair. A successful commit does not establish that the intended public page is running the change. Check the live target, deployment version, and affected element after the update.
Then repeat the customer task in the declared testing scope. Confirm whether the user can navigate, correct errors, understand relevant information, and discover the outcome. If a third-party step was not evaluated, keep that limitation explicit.
W3C states that no tool alone can determine accessibility. Automated results and human evaluation are complementary evidence, not interchangeable certifications.
Assemble an evidence packet an attorney can understand
A useful packet includes the original allegation list, assessment scope, relevant findings, repair ownership, change history, deployment information, verification outcomes, and outstanding limitations. Each conclusion should state what was evaluated and when.
Evidence section | Include | Avoid |
|---|---|---|
Allegation mapping | Original wording and corresponding task | Rewriting the allegation to match an unrelated fix |
Repair history | Confirmed source changes and responsible owners | Claiming an unmerged proposal was deployed |
Live verification | Target page, method, date and outcome | Treating an old successful result as the latest attempt |
Remaining work | Untested states, external dependencies and manual review | Hiding limitations behind a compliance badge |
Counsel decides how technical evidence should be used in legal correspondence. A technician should not invent settlement language, legal defenses, or an assertion that all obligations have been satisfied.
Keep federal business guidance and government rules distinct
The DOJ's business web-accessibility guidance explains its position on accessible online goods and services offered by public accommodations. The separate federal rule for state and local government web content has a different scope; do not automatically apply its dates or detailed requirements to every private business.
State and local obligations may also matter. This checklist does not resolve those questions. A city page identifies service geography and practical website tasks, not jurisdiction-specific legal advice or an ADAFix law office.
Continue reassessment after the urgent work
Track updates to themes, forms, apps, documents, and third-party services. Preserve a dated baseline of important tasks. Monitoring can help detect some regressions, but a low automated issue count does not establish that every customer journey remains accessible.
Communicate remaining work honestly. An accessibility statement should describe supported facts, contact routes, and known limitations rather than promise perfect conformance or immunity from claims.
Common complaint-response questions
Should we wait for a complete audit before contacting counsel?
Do not rely on this technical checklist to decide legal timing. Bring the notice and stated deadlines to qualified counsel promptly; investigation and remediation can proceed in parallel as appropriate.
Can fixing the listed barriers guarantee the case goes away?
No. Technical work cannot guarantee a legal outcome, and the alleged barriers may not describe the entire accessibility scope.
Is a score or screenshot enough documentation?
Usually it is only part of the technical record. Scope, method, dates, affected tasks, actual changes, verification, and unresolved dependencies provide important context.
Where can we see examples of practical task scope?
See New York bookings and tickets, Austin event registration, Miami hotel booking, or browse all state hubs. For platform ownership and repair limits, read the WordPress and WooCommerce guide.