An accessibility audit for a federal-vendor contract is not the thing most people picture. It isn’t a score you pass or fail. It’s a file you produce: a documented body of evidence a procurement officer can put their name to and defend if anyone ever asks. Most WordPress sites are built to do well on a quick automated scan and to come apart the moment someone asks for that file. Closing that gap is what this post is about.
If you are evaluating options, I offer WordPress for schools services across Canada.
If you’re a developer about to run a one-off Lighthouse scan the week before launch, this isn’t written for you, and you can close the tab with my blessing. This is for the procurement officers and operations leads who have to produce the accessibility attestation a federal-vendor contract requires, and who have learned that a green score and a defensible file are not the same document.
What a procurement-grade audit actually asks for
Start with the deliverable, because everything else follows from it. The audit produces a criterion-by-criterion attestation: each relevant success criterion from the Web Content Accessibility Guidelines (WCAG), checked, with a note on how the site meets it, a screenshot or a tester’s observation as proof, the name of the person who did the testing, and a remediation plan for anything not yet passing.
The output is a document. A score of 98 from an automated tool tells a procurement officer very little they can defend, for a reason worth understanding: automated scanners only catch the machine-checkable criteria. Deque, the team behind the widely used axe testing engine, puts that coverage at roughly 30 to 40 percent of WCAG. The other 60 to 70 percent need human judgement: whether the alt text actually describes the image or just fills the attribute, whether the heading order tells a coherent story to someone moving through the page by structure, whether a custom form survives keyboard-only operation. And the kind of thing no scanner will ever catch — whether an error message says, in plain words, what the person did wrong and how to fix it. The file is what survives a challenge. The score is what you glance at on the way to building it.
Where most WordPress sites quietly fail
Three patterns turn up so often in WordPress audits they’re worth naming.
The first is form labels. Contact forms built by popular plugins often ship inputs that look labelled to a sighted visitor and read as nothing to a screen reader, because the visible text was placed beside the field rather than tied to it in the markup. It passes a glance and fails a tester.
The second is heading order. Page builders happily let an editor pick a heading for its size rather than its level, so a page jumps from a first-level heading to a third with nothing in between. Assistive technology relies on that structure to navigate, so when the levels are scrambled the page is genuinely harder to use than it looks to a sighted visitor scanning it.
The third is the slow one. A site can launch clean and decay over two or three years as editorial staff change, each with a slightly different habit, until a real share of the images carry no useful description — WordPress doesn’t require alt text on upload, so nothing stops the drift. An automated scan at launch would have passed. The same scan three years on finds dozens of failures the original audit never saw. Accessibility holds up only when someone keeps tending it, and most teams have no mechanism to, so it quietly slips.
What actually goes in the file
When the work is done properly, three things live in the procurement file: a signed evidence log that walks the criterion list with proof and tester names, a remediation roadmap with dates for anything not yet compliant, and an accessibility statement written to match the rigour of that criterion list rather than the marketing-page version. A generic PDF from a third-party scanning service is none of these. It’s a marketing artefact in the costume of an attestation, and a procurement officer who knows the difference will not put their name beside it.
-
Signed evidence log
Walks the criterion list with proof — a screenshot or a tester’s observation against each relevant WCAG success criterion — and the name of the person who did the testing.
-
Remediation roadmap with dates
A dated plan for anything not yet compliant, so a procurement officer can see what’s outstanding and when it closes.
-
Accessibility statement matched to the criterion list
Written to the rigour of that criterion list rather than the marketing-page version.
Not this: A generic PDF from a third-party scanning service is none of these — a marketing artefact in the costume of an attestation.
What getting it wrong actually costs
The penalty for failing accessibility on a federal-vendor contract is rarely a fine you pay and move past. It’s a renewal block: the contract doesn’t continue until the gap is closed, and now you’re remediating against a clock somebody else is holding. Done properly at build time, a real audit and remediation tends to run between $8,000 and $20,000, depending on the size and state of the site. Forced under a renewal-block clock, with procurement stalled and the work happening in a hurry, the same job runs $30,000 to $60,000. The expensive version almost always started life as “we’ll handle accessibility later.”
The rules that anchor the conversation
This isn’t a best-practice nicety; it’s a legal obligation, and the person signing the attestation needs to be able to name the provision it satisfies.
In Ontario, that’s section 14 of the Integrated Accessibility Standards Regulation (O. Reg. 191/11), made under the Accessibility for Ontarians with Disabilities Act. It requires public-facing websites to meet WCAG 2.0 Level AA. Note the version: the law is still pinned to 2.0, even though the guidelines have moved on twice since.
Federally, the Accessible Canada Act sets the overarching duty for the Government of Canada and federally regulated organisations to find and remove barriers. The technical web requirement for federal institutions comes through Treasury Board direction, anchored at WCAG 2.0 Level AA and moving toward 2.1 AA in step with the European EN 301 549 standard. Which version your particular contract names depends on when it was written, so read the contract rather than assuming.
Most other provinces have passed accessibility legislation — Manitoba, Nova Scotia, British Columbia, and others — but their web-content standards are still being phased in, which leaves Ontario as the only province with an in-force private-sector web obligation you can point to today.
Here’s the part worth holding onto through all of that. The legal floor and the bar you should actually build to are different numbers. The floor is 2.0 or 2.1 AA depending on the contract. The bar a defensible audit measures against is WCAG 2.2 AA, the current guideline, whatever version the contract happens to name. Build to the bar and you clear the floor by definition.
One honest caveat: accessibility law is specific to your jurisdiction and your contract, and the directives change. This describes the framework as it stands in May 2026; the provision your attestation actually cites is something to confirm against your own contract and current government policy, not to take from a blog post.
If you’re holding a federal-vendor contract with an accessibility clause and you’re not certain your WordPress site can produce the file behind it, that’s a conversation worth having before the renewal clock starts, not after. The honest first step is usually smaller and cheaper than people fear, and always cheaper than the version that waits.
Product names referenced on this page — including WordPress — are trademarks or registered trademarks of their respective owners. Training offered here is independent and is not affiliated with, endorsed by, or sponsored by any of these companies.
Last reviewed June 5, 2026.
