Skip to main content
All articles

October 27, 2026·8 min read

What to Keep in an Accessibility Remediation Log

Keep a dated record of every accessibility issue, fix and retest. This guide lists the fields to record and a sample log table you can copy.

accessibilitywcagremediation-logauditrecord-keepingaccessibility-statementsmall-business

An accessibility remediation log is a dated record of every accessibility issue found on a site, the fix applied to it, and the retest that checked the fix. Remediation is the word teams use for fixing problems found in an audit or a scan. A good log answers four questions for each issue: what was wrong, where was it, what changed, and did the change work. Keep one row per issue, and never delete a row to make the log look cleaner.

Inside the team, that record stops the same issue from being fixed twice, and stops a fixed issue from quietly coming back after a redesign. Outside the team, it shows the work in order, with dates. A log does not stop a demand letter from arriving, and it does not prove a site meets a standard.

Key takeaways

  • Keep one row per issue: date, page, issue, WCAG criterion, fix, who, and retest date.
  • Write the issue in plain words first, then add the criterion number.
  • A fix without a retest is an open row, not a closed one.
  • Add new rows when new content, a new template, or a new scan adds new issues.
  • Link each row to its evidence, such as a scan report or a code change.

The seven fields every row needs

  • Date. The date the issue was found, in the same format in every row.
  • Page. The page or template where the issue appears, with its full path or URL.
  • Issue. What a user runs into, in plain words, plus the element or control involved.
  • WCAG criterion. The WCAG 2.2 success criterion number and name, when one applies.
  • Fix. What changed in code or content, in enough detail to repeat it.
  • Who. The person or role who made the fix. A role is enough for a small team.
  • Retest date. The date the fix was checked again, plus the result.

Add a status column, and use one short set of words the same way every time: open, in progress, fixed and awaiting retest, retest passed, retest failed, or deferred with a reason and a date to revisit it. A deferred row is still a live row.

Name the standard and level at the top of the log, for example WCAG 2.2 AA, and note the scope: which pages and templates were checked, and which methods found each issue. Do not stretch a sample based check into a claim about a whole site.

How to set up an accessibility remediation log

A spreadsheet works well for most small sites. One tab holds the log, and a short note at the top holds the scope, the standard, and the date of the last full check. Keep the file where the people who fix issues can reach it.

Copy these headings, then fill one row per issue. Do not merge several pages into one row unless one template change covers all of them.

Date Page Issue WCAG criterion Fix Who Retest date Status

The row below is an example, not a real client case.

Date Page Issue WCAG criterion Fix Who Retest date Status
2026-10-05 /contact Hero image had no text alternative, so screen reader users got no description of it 1.1.1 Non-text Content Added a short descriptive text alternative to the image in the page code Web developer 2026-10-08 Retest passed

Read that row as a test. A new team member could find the page, see what was wrong, and check the fix again without asking the person who wrote the row. If your rows fail that test, add detail to the issue and fix columns first.

How to write entries a stranger can follow

Write for a reader who was not in the room. "Fixed alt text" tells that reader nothing. "Added a text alternative that names the product and its color to the hero image on /contact" tells the reader what changed and where to look. The same rule applies to the issue column: "Contrast fail" is a label, while "Body text was light grey on white" is a description a tester can recheck.

Record the retest the same way you recorded the finding: date, method, and result. If the retest failed, say what still fails and set a new retest date. If the fix created a new problem, add a new row for it and point back to the first row.

Keep manual checks in the log too. A scan is a starting point, and a quick manual keyboard and screen reader check is part of good practice. Log manual findings in the same rows and name the method in the row. Review the log after each release, and on a weekly pass for a site that changes often.

What to keep with the log

The log is the index, not the whole file. Keep the evidence it points to: the scan report for each check, with its date and pages covered; the code or content change behind each fix, where one exists; short notes from manual keyboard and screen reader checks; and the current accessibility statement, updated when known limitations change. Your log is the working record behind that public page.

Keep a short scope note too: the standard and level used, the pages in scope, and anything that could not be checked, such as content behind a login. Put dates in report file names, so a report can be matched to a row in seconds. This is general information, not legal advice. If you have received a demand letter or been sued, talk to a qualified attorney.

How Axeazy helps with this exact issue

Axeazy gives you a dated record of the work, which is the raw material a log like this needs. Every scan and fix is recorded with a date and time, and reports can be exported as PDF files. Paid plans add weekly monitoring, so new problems found after a site update land in a fresh report.

The scan runs 98 automated axe-core checks across 14 fix categories, from alt text and form labels to table header structure. For a site with a GitHub repository, fixes arrive as a pull request with a visible code diff to review and merge, which gives the log a code change to point to for each row. For WordPress, the free plugin applies its three instant fixes at render time. Read the honest scope on the capabilities page and the method behind the scan on the risk score methodology page.

A scan is a starting point, and a quick manual keyboard and screen reader check is part of good practice. Add those manual results to the same log. For the public side of the record, see Axeazy's own accessibility statement. If a demand letter is part of your worry, read the demand letter guide on our blog, and keep the legal response separate from the technical log. Plans and prices sit on the pricing page.

Want a quick read on your own site? Run Axeazy's free 60 second scan . It needs no signup.

Last checked: October 26, 2026.

FAQ

What is an accessibility remediation log?

An accessibility remediation log is a dated record of accessibility issues found on a site, the fixes applied, and the retests that checked those fixes. Each row covers one issue and names the page, the issue, the WCAG criterion, the fix, the person or role who made it, and a retest date.

How is a remediation log different from an accessibility statement?

A log is a working record for your team, with one row per issue and the detail behind each fix. A statement is a public page that tells visitors about your target standard, the measures you have taken, and any known limitations, plus how to report a problem.

Should I delete rows for issues that are fixed?

No. Keep fixed rows and mark them as retest passed, with the retest date filled in. Deleting closed rows erases the history that shows work was done. If a row turns out to be a duplicate, mark it as superseded and point to the row that carries the work.

How often should I update the log?

Update the log whenever an issue is found, fixed, or retested, not only after a full audit. Review the whole log after each release, and on a weekly pass for a site that changes often.

Does keeping a log prove my site meets WCAG?

No. A log shows what was found, what was fixed, and what passed retest, but it does not by itself prove a site meets a standard. A sample based check cannot support a whole site claim on its own, and some criteria need manual review that a scan cannot do.

Sources

Check your own site

See what is actually wrong with your site.

Free, 60 second WCAG 2.2 AA scan. No credit card required.

See pricing

Scope of every report we ship: SCOPE LIMITATION: This report documents violations identified by automated WCAG 2.2 AA scanning using axe-core v4.11.0. Automated tools cannot test every WCAG criterion; many criteria require manual review. This report does not constitute legal advice, guarantee ADA compliance, or protect against legal action. ADA compliance is a legal determination made by courts. For full WCAG conformance assessment, engage an IAAP-certified accessibility professional.