Learn what a website accessibility remediation record contains, how it documents testing and repairs, and why it is not a certificate.
A website accessibility remediation record is an organized history of barriers found, repairs made, tests performed, open limitations, and ongoing ownership. It helps a business and its advisers understand what happened. It is not a certificate, legal opinion, government approval, or guarantee that the website has no remaining barriers.
Published 2026-09-22 · Last updated 2026-09-22 · By Nelson Penagos, JubilantWeb
A website accessibility remediation record is an organized history of barriers found, repairs made, tests performed, open limitations, and ongoing ownership. It helps a business and its advisers understand what happened. It is not a certificate, legal opinion, government approval, or guarantee that the website has no remaining barriers.
Websites are living systems. A team may repair navigation today, replace a form next month, and add a booking vendor later. Without a record, people cannot easily distinguish what was tested, what changed, what remains outside the team’s control, or when a regression appeared. A structured history makes maintenance more deliberate.
The record also helps technical, content, operations, and legal teams speak from the same facts. Counsel can see the defined scope and dates without relying on a marketing statement. Developers can reproduce a finding and avoid reintroducing it. Content owners can understand which publishing choices need review. Leadership can assign owners to unresolved risks without pretending every item has the same impact.
A record should remain factual. “Keyboard focus was not visible on the reservation link; CSS was changed; keyboard retest passed on the listed template and browsers” is supportable. “The website is legally compliant” is a broader conclusion that the test evidence does not establish.
Do not collect unnecessary personal data in screenshots, recordings, or test accounts. Redact sensitive details and control access. A record for a patient form, legal intake, employment application, or account portal should use authorized test data and follow the organization’s privacy and security practices.
List included domains, templates, pages, components, documents, breakpoints, user journeys, browsers, assistive technologies, and third-party systems. State exclusions plainly. A representative-page sample can be efficient, but the record should not imply that every URL was reviewed if it was not.
Record the technical benchmark as WCAG 2.1 Level A and AA for the described project. If the team also notices WCAG 2.2 concerns, report them separately unless 2.2 has been added to scope. This prevents ambiguity and still gives the business useful information about newer criteria.
Define terms such as “fixed” and “verified.” A developer marking a ticket complete is not the same as an independent retest. Likewise, an automated rule passing after a change may not demonstrate that a complete task works with a keyboard or screen reader.
Evidence should be proportionate and repeatable. It may include a concise screenshot, DOM excerpt, code reference, test steps, checker output, or notes from a keyboard and screen-reader test. Preserve enough context to understand the barrier without filling the file with inaccessible or sensitive artifacts.
For example, the “before” entry might state that submitting an empty contact form moved visual focus nowhere and did not announce the error summary with NVDA. The “after” entry could describe the focus-management and live-message change, then list the same steps and observed result during retest. Avoid claiming that one passing combination proves all combinations.
Where a subjective judgment is involved—such as whether alternative text communicates the purpose of a complex image—record the rationale and approved wording. Where a business decision limits a repair, identify who made the decision and what alternate access was considered. The purpose is accountability, not blame.
Independent validation means a person other than the original implementer checks the defined repair against the stated method and scope. That reviewer may be internal or external, depending on the engagement. Independence can reduce confirmation bias, but it should not be inflated into certification or a claim that every user has reviewed the site.
Validation can combine automated rules, keyboard operation, zoom and reflow, contrast measurement, and screen readers such as NVDA or VoiceOver. The record should name the method and relevant environment. It should also distinguish “not reproduced” from “fixed,” because a missing test condition can conceal a problem.
Booking, ordering, payment, chat, maps, portals, and embedded documents may be controlled by vendors. Record the affected task, vendor, exact reproduction steps, report date, support case, available configuration, response, and status. Do not mark an issue repaired merely because it was forwarded.
If the business provides an alternate method, describe it accurately and test that method too. Whether an alternative satisfies a legal obligation depends on facts and legal analysis; the technical record should not decide that question. It can give counsel the facts needed to evaluate it.
| Remediation record | Certificate-style claim |
|---|---|
| Defines the pages, components, methods, and dates reviewed | May imply a universal conclusion without showing scope |
| Lists fixed and unresolved findings | May reduce a changing site to a pass label |
| Shows specific evidence and responsible owners | May omit how the conclusion was reached |
| Updates as code and content change | Can appear permanent even after the site changes |
DOJ guidance points businesses to WCAG and other resources but does not operate a certification program for private business websites. A scan vendor, overlay, badge, or remediation provider should not imply government approval. The Federal Trade Commission’s 2025 accessiBe order addressed broad compliance claims and required a $1 million payment; it reinforces the need to describe product evidence precisely rather than promise an outcome.
Log material releases, content updates, automated findings, manual spot checks, user feedback, vendor changes, repairs, and retests. Assign each confirmed issue an owner and due date based on impact and effort. Preserve false-positive decisions with a short rationale so the same alert is not repeatedly rediscovered without context.
Monitoring tools can scan on a schedule, but they do not evaluate every success criterion or user journey. Add periodic keyboard and screen-reader task checks, especially after navigation, forms, account features, ordering, booking, and document workflows change. Monitoring is a feedback loop, not an evergreen score.
An attorney may ask what the organization knew, what it did, when it acted, which systems were involved, and what remains open. A clear record can answer those factual questions efficiently. It can also help counsel coordinate preservation, vendor communication, and priorities if a demand letter arrives.
Do not edit or characterize records to manufacture a legal defense. Follow counsel’s instructions about privilege, retention, and communications. The web team should provide accurate technical facts and avoid legal conclusions. For response planning, read the Florida demand-letter guide.
Request a free website accessibility scan for a starting set of detectable barriers. It is a request form and does not produce instant or complete audit results. JubilantWeb’s website accessibility remediation service describes code repair and documentation. The cost guide explains scope and pricing, while the WCAG 2.1 AA guide explains the benchmark.
We review the submitted site and return a plain-English summary. This is a request for review, not an instant public scanner or legal advice.
No. It is a factual history of defined testing, findings, repairs, retests, limitations, and ownership. It should state its scope and avoid universal conclusions. DOJ does not certify private business websites through its general web guidance, and a vendor record should never imply government approval or guarantee a legal outcome.
For the work described here, use WCAG 2.1 Level A and AA as the technical benchmark and connect each relevant finding to a success criterion. Report WCAG 2.2 observations separately unless 2.2 is added to scope. The record should also include task-based findings that need context beyond a criterion number.
Yes. Retaining the original observation, repair, date, method, and retest result preserves useful history and helps prevent regressions. Mark the current status clearly rather than deleting the entry. Follow the organization’s retention, privacy, security, and legal guidance, especially when evidence could contain sensitive information.
No. Automation can populate specific findings and dates, but people must confirm results, document user impact, make repairs, and test keyboard, screen-reader, reflow, document, and task behavior. The record should show which method produced each result rather than blending automated and manual evidence into one unexplained score.
Record the vendor, affected task, exact steps, user impact, report date, support case, available configurations, response, owner, and next action. Keep the status open or vendor-dependent until verified. If an alternate method is offered, document and test it without asserting that it resolves the organization’s legal obligations.