Yes, if you can open a dated, owned record that shows the public task, the barrier, the corrective decision, and the retest result. When someone cannot submit a permit application, enroll a child, or read an emergency notice, restoring access is the immediate priority; a complaint also asks the institution to account for its response. For covered state and local government entities, the U.S. Department of Justice’s 2024 Americans with Disabilities Act Title II web accessibility rule makes disciplined operational records especially important.
Build that record before a complaint arrives, then update it when a material service, template, component, or supplier release changes. An accessibility evidence packet does not establish legal compliance or replace legal advice. It is a practical institutional record, one that lets accessibility, communications, procurement, records management, technology, and legal staff work from the same account while counsel addresses obligations and response decisions.
Run a complaint rehearsal before you need one
Rather than beginning with a broad audit plan, put one consequential public task on the table and ask whether your institution could explain it tomorrow. Choose a journey involving housing, education, care, benefits, payment, or urgent information. An accessibility evidence packet is a structured record for that one service or closely related journey, connecting a reported barrier to a precise URL, responsible owner, corrective work, and verified outcome.
Use Web Content Accessibility Guidelines 2.1, a World Wide Web Consortium standard organized around testable success criteria, to describe observations where it applies. The ADA Title II final rule adopts WCAG 2.1 Level AA for covered entities’ web content and mobile applications, subject to its scope, compliance dates, and exceptions; confirm those details in the Department of Justice rule resources, not in a generic checklist.
Check: Start with the service whose interruption carries the greatest public consequence. A modest, current record for a benefits renewal journey is more useful than an immaculate archive that cannot explain a live service.
Could you identify the exact service state?
Start with a service inventory: the plain-language task, entry URL, critical steps, release date, application or content management system owner, and supplier where relevant. A service owner is the institutional role accountable for coordinating a public task across content, technology, and suppliers; that role does not have to make every repair.
Record the authority that applies to the institution. Section 508 is the federal accessibility framework for information and communication technology, while ADA Title II applies to many state and local government entities. A university, hospital, library, or nonprofit may instead have duties arising from other laws, contracts, policies, or funding conditions, so a single label is not a universal answer.
Could another reviewer reproduce the barrier?
Write the finding in terms of the task it interrupts. “Button inaccessible” leaves the next reviewer to guess. “On the payment step, keyboard focus moves from the card-number field to the footer and bypasses Submit payment” identifies a condition another person can examine. Record observed behavior and reproduction steps before attaching a WCAG criterion.
For example, WCAG 2.1 Success Criterion 2.1.1, Keyboard addresses keyboard operation, while Success Criterion 2.4.7, Focus Visible addresses a visible keyboard focus indicator. A control may receive focus without showing it, or show focus while remaining inoperable; separate records keep one checkmark from concealing two defects.
Attach evidence that explains the condition to someone who was not present. A screenshot can preserve a visual state, while a brief recording, code reference, or interaction log may better explain behavior. This need not require elaborate tooling: a controlled folder and shared tracker can serve a small team when records are findable and have an owner.
Read the packet as a chain of custody for a public task
| Packet record | What it captures | Question it answers |
|---|---|---|
| Service inventory | Journey, URLs, owner, supplier, release date | What public service is in scope? |
| Finding record | Barrier, steps, criterion, capture date | What condition was observed? |
| Remediation record | Decision, change, owner, target release | What corrective work was authorized? |
| Retest record | Method, result, date, reviewer | What happened after the change? |
Could you show who decided to repair it?
Public institutions often work through shared design systems, contracted platforms, release freezes, limited communications windows, and procurement processes. Capture those conditions without treating them as the final answer. The packet should identify who accepted the finding, who owns the repair, whether a supplier must act, the expected release, and any interim route through which the public can complete the task.
A remediation record is the dated account of a corrective decision and the work attached to it. Link it to the ticket or change request, name the responsible person or team, and describe an observable expected result. “Improve form accessibility” cannot be meaningfully retested; “restore keyboard operation for date selection and preserve visible focus on Continue” can. When content authors revise instructions, labels, or documents rather than software, preserve before-and-after URLs or files and the approving owner.
Avoid: Treating an automated scan as the whole record. The W3C guidance on evaluating web accessibility with tools describes automated tools as part of a broader evaluation approach requiring human judgment. Retain useful scan results, then add task-based evidence for conditions the scan cannot establish.
Could you show what happened after the repair?
A retest asks one bounded question: after the stated change, can a person complete the same task under the recorded conditions? Repeat the original route, name the reviewer and date, and record pass, still failing, changed but unresolved, or unable to retest. “Unable to retest” is an honest operational state when access, accounts, or a supplier release is missing; assign an owner and next review date instead of closing the issue.
Review the public journey rather than merely the repair ticket. A benefits form can require entry, validation, error recovery, review, and submission; a university portal requires the student-facing task rather than an administrative preview. The W3C Website Accessibility Conformance Evaluation Methodology, a method for defining scope, selecting samples, and documenting results, offers a useful model for making that boundary explicit.
Make the record usable in the response room
Maintain one index a responsible manager can open without searching personal inboxes or disconnected supplier portals. Link the current inventory, open findings, completed remediations, retests, related correspondence, and named owners. Restrict editing where appropriate, while giving response staff sufficient read access to coordinate; evidence held in one specialist’s workspace is difficult to use as an institutional record.
Review the packet after major releases, supplier updates, and changes in service ownership. Its purpose is not to manufacture certainty. Its purpose is to let the institution explain current knowledge, decisions, and next action with the care it expects from people using the service.
Key takeaways
- An accessibility evidence packet should connect each public service to dated findings, remediation decisions, and retest results.
- A URL is incomplete evidence unless the record also identifies the task, capture date, environment, and responsible owner.
- Automated results can support an accessibility record, while task-based human review documents conditions that tools cannot establish.
- A retest should repeat the affected public task and record an explicit outcome, including when the team cannot yet retest.
Questions readers ask
Does an evidence packet prove that our institution is legally compliant?
No. It documents work and decisions the institution can substantiate; applicable obligations depend on the entity, service, rules, facts, and relevant exceptions. Consult counsel for legal conclusions and use the Department of Justice’s ADA Title II rule resources for scope and implementation details.
What should we document when an automated tool finds an issue?
Save the relevant result, then record the affected task, URL, observed behavior, date, owner, remediation decision, and retest. The W3C evaluation guidance explains why tools belong within a broader process.
Who should own the evidence packet?
Assign a named service owner to coordinate content, development, procurement, and accessibility work. Technical reviewers and suppliers can contribute evidence, while the institution should retain visible responsibility for the record.
How often should we update accessibility evidence?
Update it when a material public task, template, component, or supplier release changes, then review it on a recurring schedule appropriate to the service’s consequence. A useful packet can explain the service the public can use today.