Turning accessibility checks into a dated monthly evidence and regression workflow

What was happening

Legal counsel asked for continuing accessibility work to be documented with dates. The site also changed often enough that a clean April result could not be assumed to describe the site in July. Internal records therefore evolved from a homepage remediation summary into repeatable evidence packs and a larger page-by-page report.

Why the obvious solution was not enough

A monthly audit can become performative if it only records scores. It also becomes unmanageable if every run starts from scratch. The workflow needed stable representative URLs, consistent tool roles, a clear issue status model, and change-triggered retesting between scheduled audits.

How the solution works

1. Keep a stable representative URL list so month-to-month results are comparable, then add temporary URLs when a new template or feature needs coverage.
2. For each page, retain the tool, device, date, result summary, evidence screenshot/export, and any finding that requires remediation or manual review.
3. Use issue states such as open, fixed, manual review, third-party, or accepted after review instead of reducing everything to a single score.
4. Rerun WAVE, axe DevTools, and Lighthouse/PageSpeed after major theme releases, app installs, marketing widgets, or other third-party changes instead of waiting for the next calendar audit.
5. Preserve manual keyboard and interaction checks as first-class evidence. A resolved scanner error does not replace testing focus order, Escape behavior, hidden controls, zoom/reflow, and dynamic messages.
6. Separate accessibility findings from performance findings in the report. Lighthouse can provide both, but a performance score is not an accessibility ruling and an accessibility score is not legal certification.
7. Retain the issue history so a recurring defect can be traced to the theme/app change that reintroduced it.
8. Keep the report useful to developers and nontechnical stakeholders: executive summary first, detailed findings and remediation next, evidence appendix last.

What should be verified before shipping

• Use the same naming convention and tested URL set across recurring reports.
• Keep screenshots/exports dated and associated with the exact page and device tested.
• Record unresolved manual or third-party items explicitly instead of silently omitting them from the next report.
• Trigger an out-of-cycle retest after major app, theme, tracking, or interactive-component changes.
• Make sure the report distinguishes automated evidence, manual evidence, and items still awaiting assistive-technology review.
• Keep the report understandable to legal/operations stakeholders without turning engineering findings into unsupported compliance promises.

What changed

Accessibility documentation became repeatable evidence of maintenance over time. The April internal summary, May insurance-oriented evidence package, and July expanded report showed the progression from one-time remediation toward a sustained monitoring process.

Reusable lesson

The useful unit of accessibility documentation is not the screenshot; it is the audit cycle. Consistent evidence, issue history, and retesting after change make the record meaningful.