Website accessibility fix log: keep a dated before-and-after record and re-test

How a small business can keep a simple, dated record of website accessibility fixes: a spreadsheet fix log, before-and-after evidence worth saving, how each fix was tested, and when to re-test after updates.

When you fix accessibility problems on your website, write down what you fixed and when. A simple, dated record helps your web person avoid undoing fixes, helps you re-test after every change, and gives you a clear answer when a customer, client or advisor asks what you've done. This guide shows a plain fix log any small business can keep in a spreadsheet, what before-and-after evidence to save, and how often to re-test.

1. Why keep a record at all

Fixes get undone. A theme update, a new plugin or a redesign can quietly bring back missing labels, low contrast or a broken menu. A log tells you what to re-check.
It shows real work, not promises. A list of dated fixes, with what was tested and how, says more than a badge or a statement alone.
It makes handoffs easy. If you change web designers, the new one can see what was already done.
Advisors ask for it. If you ever get a complaint or a demand letter, a lawyer may ask what you've fixed and when. Talk to a lawyer about any letter first; see what to do after an ADA website demand letter.

2. A simple fix log (copy these columns)

One row per problem. A spreadsheet is enough.

Date found | Page (URL) | Problem | How found | WCAG criterion | Fix made | Date fixed | Fixed by | Re-tested how | Re-test date | Result
2026-11-09 | /contact | Email field has no label | automated scan | 1.3.1, 4.1.2 | Added visible "Email" label | 2026-11-10 | web designer | scan + screen reader | 2026-11-11 | pass

(The row above is example data.) Write the problem in plain words, the way a visitor would feel it, and note the WCAG criterion if your report gives one, such as 1.3.1 or 4.1.2.

3. Always note how each problem was found and re-tested

Automated scans find only part of the barriers on the pages they visit. Keep that honest in your log by saying how each item was found and checked: automated scan, keyboard test, screen reader test, zoom test, or a report from a visitor. A fix that "passes the scan" may still be hard to use, so for menus, forms, booking and checkout, add a quick keyboard run (keyboard test) and a short screen reader test.

4. Before-and-after evidence worth saving

The scan report or checker results from before you started, with its date.
The report from your re-scan after fixes, with its date.
Screenshots of the page before and after for visual fixes such as contrast, focus outlines or text in images.
A short note of keyboard and screen reader results for your most important tasks: contact, booking, ordering, paying.
Any messages from visitors who reported a problem, and your reply.

Save them in one folder named by date, so you can find them later.

5. When to re-test

Right after a batch of fixes.
After any theme, template, plugin or app update.
Before launching a new page, menu, booking tool or checkout.
After a redesign or platform move; see the redesign and migration checklist.
On a regular schedule, such as every month or quarter; see a website accessibility maintenance plan.

6. Link it to your accessibility statement

Your accessibility statement should say how people can report a problem. When a report comes in, add it to the log, fix it, and reply. Keep the statement honest: describe what you've tested and what you know still needs work, rather than claiming the site is "fully compliant".

Common mistakes

Fixing things with no record, then a redesign undoes them.
Writing "site is ADA compliant" in the log or on the site after one scan.
Only saving the "after" report, with nothing showing what changed.
Never re-testing the booking, contact or checkout flow with a keyboard.
Relying on an overlay widget as the fix; see overlays vs real fixes.

A 10-minute start today

Make a spreadsheet with the columns above.
Run a free homepage snapshot or another free checker and save the result with today's date.
Add each problem as a row.
Tab through your contact or booking page and add anything you couldn't reach or see.
Put a re-test date on your calendar.

What a scan can and can't do here

Our scan reports are dated PDFs of what an automated axe-core scan found on the pages you choose, with copy-paste fixes. The $149 Fix-Pack covers up to 10 pages and includes one re-scan after you apply fixes, so you get a dated before and after for the automated part. It can't test with a keyboard or screen reader for you, judge whether a fix is easy to use, or tell whether your site meets any law.

Handing sites over to clients? See the client handoff checklist and the agency 5-pack ($499, five white-label reports, use within 12 months).

This is general technical guidance, not legal advice. Keeping a record doesn't certify compliance with the ADA or any law, or protect against claims.

Want the fixes written for you?

Start with a free homepage snapshot. The $149 Fix-Pack scans up to 10 pages and gives copy-paste fixes for your platform within 48 hours, with a 14-day refund promise. See a sample report first.

This is general technical guidance, not legal advice, and it does not certify compliance with the ADA or any law.

Related guides

All guides

This guide is general technical information, not legal advice. Following it does not certify ADA or any legal compliance. Automated checks find only part of accessibility barriers.

Check your own site, then decide

Free homepage snapshot. Your top 3 issues in about a minute. No signup, no card.
$149 Fix-Pack, if you want the full list. Up to 10 pages scanned, issues ranked by impact, copy-paste fixes for your platform, delivered within 48 hours, plus one re-scan after you apply them.

Get my free snapshot Order the Fix-Pack – $149

14-day refund promise. See a sample report first. A technical report, not legal advice; automated checks find only part of accessibility barriers.