Writing Down What You Fixed

The document nobody starts

A month of accessibility work produces a better site and no record that any of it happened.

Six months later nobody remembers what was tested, what was fixed, or what was deliberately left.

So the same problems get rediscovered, the same decisions get remade, and there is nothing to show anybody who asks.

One document, written as you go, solves all three and takes a line per item.

What goes in it

• The date of each check.
• What you tested and how.
• What you found.
• What you fixed and when.
• What you deferred and why.
• Who did the work.

The fifth is the one that turns a list into evidence. Recording that you know about something, judged it lower priority, and intend to address it is a materially different position from having never looked.

Deferred is not the same as ignored

Which is worth being clear about.

Nobody expects a small business to have a perfect site, and nothing requires it.

What distinguishes a business acting reasonably is knowing what is wrong and having a position on it.

Written down, that reads as an ongoing programme rather than as neglect, because it is one.

Undocumented, exactly the same situation looks like nobody has ever thought about it.

The document is the whole difference between those two readings.

A worked example

A business kept a simple table through two days of fixes: date, what, found, done, outstanding.

Eight months later they were asked, in a tender for public sector work, what steps they had taken on accessibility.

Most bidders answer that question with a general assertion.

They attached the log, showing dated testing, specific fixes, a paid session with a screen reader user, and four items with target dates.

They were told afterwards it was the strongest answer received on that question.

The document had taken about fifteen minutes to maintain in total.

It becomes the public statement

Which is the second use and costs almost nothing.

An accessibility statement on your site is a short page saying what standard you are aiming at, what you know is not yet right, and how to tell you about a problem.

Your log contains all three, so the statement is a summary of it rather than a separate exercise.

Keep the public version brief and honest, without the internal detail.

The contact route matters most: a named way to report a problem, that somebody actually reads.

A statement claiming full compliance is worse than one admitting a list, since the first is checkable and usually wrong.

Record the tests, not only the fixes

Which is the part people omit.

Tested the keyboard journey on 28 August, found three issues, is a useful line even where nothing was fixed that day.

It establishes when the site was last looked at and by what method.

It also means a problem appearing later can be dated to after that check, which tells you it was introduced by a change.

A test that found nothing is worth a line for the same reason.

Note what a change might have broken

Since this is where regressions come from.

When the site is redesigned, a plugin updated, or a booking widget added, note the date in the same document.

Then retest the keyboard journey and the form, which takes fifteen minutes.

Most accessibility problems on a maintained site are reintroduced rather than original, and the log is what makes that visible.

Without it, the same three issues get found and fixed every two years by somebody who thinks they are new.

Keep it where the business keeps things

On the same terms as everything else.

A plain document, in the business's own storage, alongside the hosting details and the annual review notes.

Accessible to more than one person, and dated at every entry.

Review it once a year with everything else, and add the year's testing to it then.

Fifteen minutes a year keeps it current once it exists.

The hard part is starting one, and the easiest moment is immediately after doing some of the work, when you still remember what you did.

Write down the last two days now rather than intending to reconstruct them later, since reconstructing a log is considerably harder than keeping one.

One line per entry is enough

Since the reason these documents do not exist is that people imagine something formal.

Twenty-eight August, keyboard walkthrough, cookie banner cannot be dismissed, fixed thirtieth, is a complete and useful entry.

It needs no template, no headings, no severity ratings, and no reference numbers, all of which are how a simple log turns into a project nobody maintains.

A plain table with five columns in whatever software you already use is the correct level of formality for a small business.

Anybody who later needs it in another format can produce one from this, and nobody can produce this from nothing.

It also protects whoever comes next

Which is the same argument that applies to every record in this business.

A developer inheriting the site, a new member of staff, or a supplier taking over maintenance all arrive with no idea what has been considered.

Without the log, they either redo work that was done or undo a fix without knowing it was deliberate.

The second is the expensive one, and it is how a focus indicator that somebody restored gets removed again in the next redesign.

A line saying focus style added deliberately, do not remove, prevents that permanently and costs nothing.

The counter-case

A record is not a defence.

Documenting a problem does not resolve it, and a log listing the same four outstanding items for three years reads worse than no log at all.

Small businesses also have limited appetite for documentation, and one nobody maintains is worse than none.

And this matters far more for anybody selling to the public sector than for a business that never will.

Keep one dated document listing tests, fixes, and deferrals, publish a short honest statement from it, and retest after any change.

The document

1. One table, dated entries.
2. Record tests as well as fixes.
3. Record deferrals with reasons.
4. Note who did the work.
5. Add a line after any site change.
6. Publish a short statement from it.
7. Review it annually.

Step three is what turns a list of work into evidence of judgement, since knowing about a problem and having a position on it is a different thing from never having looked.

The public version is covered in an accessibility statement for a small site.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.