AODA compliance
You have an accessibility obligation. The hard part is knowing whether you actually meet it.
Most organizations find out they are non-compliant from a complaint, a procurement questionnaire, or the week the report is due. I test and verify accessibility across Confederation College's web estate — several thousand pages, under the same obligation you have — so here is what I would tell you: what the law asks for, who it applies to, and how to tell where your site stands.
From $2,500 for a position check · from $6,500 for a full conformance audit
Not sure which one you need? Send me your URL and your headcount and I will tell you, before any question of an audit.
The law
What AODA actually requires of a website
Ontario's Integrated Accessibility Standards Regulation asks for one measurable thing of public websites: they must meet WCAG 2.0 Level AA, with two carve-outs — live captions and pre-recorded audio descriptions. That applies to designated public sector organizations and to businesses and non-profits with 50 or more employees, and it covers web content published after January 1 2012.
Two details catch people out. This is not a future deadline — the compliance date was January 1 2021. And the obligation follows whoever controls the site, including through a contract, so "our agency built it" does not move the responsibility.
Sources: ontario.ca — how to make websites accessible. Checked August 2026. This page is a practitioner's summary, not legal advice.
Filing
December 31, 2026
The compliance report — and who owes one when
Filing the accessibility compliance report is a separate obligation from meeting WCAG, with a different size threshold. This is the single most common mix-up:
| Who | How often | Status |
|---|---|---|
| Businesses and non-profits with 20+ employees | Every three years | Next due December 31, 2026 |
| Designated public sector organizations | Every two years | Was due December 31, 2025 — overdue reports are still owed |
| Organizations with 50+ employees (and public sector) | Ongoing | Websites must meet WCAG 2.0 AA — in force since January 1, 2021 |
So a 30-person non-profit files a report but is not held to the web standard. A 60-person company is held to both. Worth knowing which one you are before anyone asks.
Source: ontario.ca — completing your accessibility compliance report. Checked August 2026.
Signs
You are probably not compliant if any of this is true
In 2023 Ontario ran 972 verification audits. Among everything it checked, providing accessible websites and web content came back at 6% compliance — the lowest result in the report. Publishing the accessibility report itself managed 33%.
None of the following needs a specialist to spot, and they are the failures that show up on almost every site I audit.
- PDFs are the main way you publish documents, and nobody has checked whether they are tagged.
- Staff upload images through a CMS and alt text is optional in the form.
- Your colour palette was chosen for brand, and contrast was never measured against it.
- Video is embedded with auto-generated captions nobody has corrected.
- You cannot complete your main form — booking, application, contact — with the keyboard alone.
- Your accessibility statement claims a conformance level that no one has tested.
A published claim you cannot support is worse than no claim — it is the first thing a complaint quotes back at you.
Compliance figures: ontario.ca — AODA annual report 2023. These are rates among the organizations Ontario audited, not a survey of every Ontario business.
Method
Two ways to find out where you stand
Both are priced on how many page types you have, not how many pages. The difference between them is what the result is strong enough to carry.
Position check — from $2,500, about two weeks
For when the real question is what you sign in December. Your main template group and the one journey that matters — the application, the booking, the form people actually complete — tested by hand. Then which obligations apply at your employee count, and what you can honestly answer on the compliance report today.
Enough to sign the report where your site is one CMS on shared templates and the people who publish into it report to you. Not enough where departments run their own sites or subdomains, or where anyone outside your organization — a procurement reviewer, a complainant, a funder — will read the result. It is a position, not an evaluation, and it will not survive being read as one.
Conformance audit — from $6,500, three to four weeks
The five-step evaluation set out in W3C's WCAG Evaluation Methodology, against WCAG 2.1 Level AA — run by hand and with tooling, because automated checkers find the mechanical failures and miss most of what creates the risk.
- Scope, agreed in writing. What is in and what is out, down to third-party widgets and anything behind a login — and the browsers and assistive technologies the result covers. That last one protects you as much as me: without it, "it does not work in my screen reader" is a warranty with no edges.
- Three sample sets, not one. A structured set covering your page types, essential functions and technologies — a 4,000-page site is usually twelve of those and four document types. Then an additional random 10% on top. Then every multi-step process — apply, book, pay — included whole rather than sampled in pieces.
- Test. An automated pass clears the mechanical layer, then keyboard-only and screen-reader testing for what tools cannot see, plus the document sample.
- Check the sampling against itself. If the random set turns up a kind of failure the structured set missed, the sample was not representative — so it is drawn again and the work repeats until it holds.
- Report, prioritize, and walk you through it. Every finding against its success criterion with location and fix, ordered by real user impact rather than by criterion number, shown to you on your own site. That last call is the part that changes how the team publishes afterwards.
Enough to put in front of a procurement reviewer, a complaint or a board. One thing said plainly, because it will be quoted back at you eventually: a WCAG conformance claim cannot be made for a whole site on the strength of a sample. What you get is what was evaluated and what was found, which is what a procurement reviewer is equipped to read.
Fixing what either one finds is quoted after it, not before — and a verification re-test afterwards is what turns "we fixed it" into a dated record.
Deliverables
What you actually receive
From either
- A reporting position, written for your certifier. One page for the director who has to sign: which obligations apply at your headcount, what you can honestly answer on the Information and Communications question today, and what goes in the comment box if the answer is no. A practitioner's position, not legal advice.
- A findings register you can work from, already in fix order. One row per finding — criterion, location, severity, user impact, the fix, the effort, the template it belongs to — ordered so the change that closes forty instances comes before the one that closes one. Delivered editable and importable into your tracker. A PDF gets read once; a register gets worked.
- A call where I show you the failures on your own site. Not a presentation of the document — the document is already yours by then.
From the audit as well
- The evaluation report. Who tested, when, against what, on which browsers and assistive technologies, over which samples and how those were chosen — then the findings, with at least one worked example for every criterion not met. This is the document a procurement reviewer knows how to read, and producing it is most of what the audit costs.
- An accessibility statement, drafted. Dated, naming the standard and version, what was covered, and any part that is not conformant and why. This one comes only with the audit, deliberately — a statement is a public claim, and the position check has not looked at enough of your site to support one.
- The evidence behind it. Archived samples and screenshots, the tools and their versions, the browsers and assistive technologies, the dates. You may be audited or inspected, and this is what answers that. It cannot be assembled after the fact.
- The walkthrough recorded, with short clips of the worst barriers as a keyboard or screen-reader user meets them — so it still works after whoever attended has moved on.
After
What usually happens next
An audit is a diagnosis, and diagnoses are only useful if something follows. Three paths, and I will tell you which one you are on:
- Remediation. The site is sound and the failures are fixable in place. Most common outcome.
- Rebuild. The platform fights you on every fix. Remediating a site that cannot hold the fixes is money spent twice.
- Your own team, with training. If you have developers, the report plus a working session is often all you need.
Ongoing
Staying compliant between audits
Most organizations pay for accessibility twice. They fix everything, file the report, and two years later the site has drifted back — a new landing page, a redesigned form, forty PDFs uploaded by a department that was never told. The second audit finds much of what the first one did.
The alternative is to make the checks part of how the site runs. That is AccessibilityOps. It is built once, then it operates:
- Checks on every release. Accessibility tests run in your build pipeline alongside the ones you already have, so a regression is caught before it reaches the public site rather than at the next audit.
- A scheduled crawl of the live site. Published content is where the drift actually comes from, and it never goes through a build. The crawl catches what your developers never touched.
- Alerts that name the template. Findings grouped by the component that caused them, so one fix closes forty instances instead of forty tickets closing one each.
- A manual pass each quarter. Keyboard and screen-reader testing on your main journeys, because that is the part no scanner can judge — and it is where most of the real risk sits.
- A dated record. What failed, when it was found, what fixed it, and how it was retested.
When the compliance report comes round, you are describing a program with dates attached instead of reconstructing two years from memory — and if anyone ever challenges you, a remediation history is the difference between a defensible position and a promise.
A build engagement to put the checks in place, then a monthly retainer to run them. Both are scoped once the audit has shown how much site there is to watch.
It suits organizations that publish continuously or ship code regularly. If your site changes twice a year, you do not need this and I will say so — a re-test against the old findings is the cheaper honest answer.
How it runs
What the checking actually looks like
This is how Confederation College's estate is checked today, on every build, and it is the same rig I put on a client site.
- Automated accessibility checks on every build. Not a monthly crawl — a gate. A page that introduces a violation is caught before anyone sees it, which is the only way a large estate stops drifting between audits.
- End-to-end journeys, driven in a real browser. The forms, the search, the paths a person actually takes. A page can pass every automated rule and still be impossible to complete.
- Link and document sweeps. Broken links and moved documents surface on a schedule instead of in a complaint.
- A dashboard, and an alert when something breaks. Results land where the team already works. Nobody has to remember to go and look.
Limits
When to call someone else
- Anyone wanting an overlay widget. The accessibility toolbars that promise instant compliance do not deliver it, and they have attracted lawsuits. If that is the purchase, we are not a fit.
- Software vendors needing a VPAT or ACR. That is product conformance testing — a different discipline. I do websites. I will say so rather than improvise.
- Anyone who wants the report to say "compliant" regardless. The report says what the testing found.
Evidence
Accessibility in practice
Work where accessibility set the constraints from the start, rather than being checked at the end.
The estate moved onto modern rails without losing URLs or search visibility, and accessibility became something checked on every build.
Several thousand public pages, content owners across dozens of departments, a statutory accessibility obligation, a small team, and no option to take the site down while you fix something.
Shelter House
shelterhouse.on.ca (opens in a new window)
Emergency shelter and community services, Thunder Bay
Help is one tap from the homepage, and the site has kept up with them since.
People arrive at a site like this in a crisis, often on an old phone, needing one specific answer immediately. The site also has to hold up in front of funders.
Questions
Questions I get asked
What is your background in this?
Accessibility across Confederation College's web estate — thousands of pages, dozens of departments publishing, and an institution that has to file a compliance report. It is checked and verified every week rather than audited once a year, and working at that scale is where the method came from: test templates rather than pages, treat it as a publishing problem before a code problem, and fix by user impact rather than in criterion order. If your procurement process has specific requirements, tell me early and we will work to them.
Can a tool just tell us?
Partly, and W3C is blunt about the limit: no tool can determine whether a site meets the standard. Automated checkers reliably find contrast failures, missing alt attributes and broken landmarks, which are real problems worth fixing. They cannot tell whether your alt text is meaningful, whether a keyboard user can escape your modal, or whether your form errors make sense read aloud. That is most of the risk, and it needs hands. What tools are good for is watching for regressions between audits, which is a different job.
We fixed everything last year. Why did it come back?
Because the fixes were applied to the site as it stood, and the site kept moving. New pages, a redesigned form, documents uploaded by a department nobody looped in. This is the normal outcome, not a sign the first audit was bad. Keeping the checks running is what stops the second audit finding the first one over again.
We were audited two years ago. Do we need another?
Depends what changed. If the site has been rebuilt or the CMS has been feeding it new content weekly, yes — accessibility slips back. If little has moved, a smaller re-test against the old findings is usually the honest answer, and cheaper.
What does remediation cost?
Not knowable before the audit. What I can say is the shape: a handful of template-level fixes usually resolves the majority of instances, and document remediation is priced per document because that is what actually drives the effort.
Does WCAG 2.2 apply yet?
The regulation names WCAG 2.0 AA. In practice I test to 2.1 AA, because it is the standard federal procurement uses, it is where the sector is heading, and the extra criteria are mostly things you would want fixed anyway. I will flag 2.2 items separately rather than bill you for a standard you were not asked to meet.
How long does it take?
About two weeks for a position check, three to four for a full conformance audit — driven by how many page types you have rather than how many pages, and by how many multi-step processes have to be tested end to end. If a procurement deadline is closer than that, say so and I will scope to the deadline rather than quietly miss it.
Do you fix what you find, or just report it?
Either. The audit stands alone and you can hand it to your own developers, which is often the right answer if you have a team. If you would rather I did the work, remediation is quoted separately once the audit tells us both how big it is.
Find out where you actually stand
Ontario WCAG 2.1 AA Public sector & non-profit
Send me your URL
Your site address and roughly how many people work there. You will get back which obligations actually apply to you and what I would look at first — before any question of an audit.
Goes straight to me. No list, no automated sequence — see the privacy policy.