Accessibility Statement31 October. Sixty-one days to 31 December 2026.
Somewhere in an Ontario company right now there is a 60-page PDF sitting in a developer's inbox with the subject line "accessibility audit". Nobody has opened it since Tuesday.
Not laziness. The document is unusable.
Three situations. One of them is yours.
A) You paid for an audit and received a PDF that says "improve accessibility" without saying where.
B) Your developer opened it, could not tell which pages were tested, and closed it again.
C) Nobody sent an audit at all, and the deadline is counting down anyway.
A report a developer cannot act on is not a cheap report. It is a report you paid for twice — once to the auditor, and again in the weeks your team spends guessing.
What a usable report actually contains, one line per barrier:
— The criterion. Not "accessibility", but 3.3.2, 2.4.7, 1.4.1. A number your developer can look up.
— The exact place. The page and the element, not "the contact section".
— How to reproduce it. Three lines, keyboard first, so anyone can see the barrier in thirty seconds.
— How to verify it. The test to run after the fix, so "done" means something.
Four fields. That is the whole difference between a document that gets filed and a document that gets worked through.
The inconvenient part, said plainly: we do not touch your code. Your team fixes it, or your agency does. We retest the month after and reissue the record with the new date. If you were hoping to hand the whole thing to a supplier and never think about it again, that supplier is a development agency, not an auditor — and it will cost considerably more than an audit.
Write A, B or C in the comments. I read each one and reply personally with what I would ask your auditor to send you before you pay the invoice.
Then send this to your developer. They have been waiting for someone to say it.
