A lot of Canadian organizations still talk about the Accessibility for Ontarians with Disabilities Act as something they need to "get ready for." That framing is out of date. The website accessibility requirement under the AODA's Information and Communications Standard set January 1, 2021, as the deadline for large organizations and the broader public sector to make their public-facing websites and web content conform to WCAG 2.0 Level AA. That date has been behind us for more than five years. The question for most organizations reading this is not whether the law applies to them yet. It is whether they were ever actually compliant, and whether they still are.
The scope catches more organizations than most people assume. Under Ontario Regulation 191/11, public sector organizations of any size and private sector or non-profit organizations with 50 or more employees are required to meet WCAG 2.0 AA on their public-facing web content. Fifty employees is not a large company by most measures. It is a mid-sized regional retailer, a multi-location clinic group, a provincial trade association, a growing software company that has not thought about accessibility once since incorporation.
The Fact: The AODA's WCAG 2.0 AA website deadline for large organizations and the public sector was January 1, 2021, and has not moved. (Source: Ontario Regulation 191/11, Integrated Accessibility Standards)
What "WCAG 2.0 AA" Actually Means Here
The AODA references WCAG 2.0 Level AA specifically, not the newer 2.1 or 2.2 versions. That matters in two directions. First, it means the legal floor in Ontario is technically a step behind the standard most other jurisdictions and most enterprise procurement teams now expect, which is WCAG 2.1 AA at minimum. Second, and more practically, it means an organization that only ever targeted the literal letter of the AODA may be missing criteria that WCAG 2.1 and 2.2 added, things like consistent input purpose identification for forms, or minimum target size for touch controls, that show up constantly in real usability complaints even though they are not technically required by the Ontario regulation's plain text.
The federal Accessible Canada Act adds another layer for federally regulated organizations, banks, telecoms, broadcasters, and federal Crown corporations, and it points toward WCAG 2.1 AA rather than 2.0. An organization operating across provinces or with any federally regulated business line should treat WCAG 2.1 AA as the real target, not WCAG 2.0 AA, regardless of which specific statute technically applies to which part of the business.
The Reporting Deadline Most Teams Have Not Noticed
Website conformance is not the only obligation on the calendar. Private sector and non-profit organizations with 20 or more employees are required to file an Accessibility Compliance Report confirming they meet their AODA obligations, and the next filing deadline lands December 31, 2026. This is a distinct requirement from the website conformance deadline itself. An organization can be five years late on WCAG 2.0 AA conformance and still be scrambling to file a compliance report that, if filed honestly, would have to acknowledge exactly that gap.
This is where a lot of organizations get caught flat-footed. Compliance reporting is a paperwork deadline with a fixed date on a calendar, easy to track. Website conformance is an ongoing technical state that degrades quietly every time a new page, a new component, or a redesigned checkout flow ships without an accessibility review. An organization can pass its 2021 review and be materially non-conformant again by 2023 simply through normal product development, with nobody noticing until the next audit, or until a complaint.
What Enforcement Actually Looks Like
AODA enforcement runs through the Ontario government's compliance and enforcement process rather than private civil litigation as the primary mechanism, which is part of why some organizations underestimate the risk relative to, say, US ADA Title III exposure. Non-compliance can still result in director's orders, mandatory management plans, and financial penalties. And for organizations doing business with the public sector, or bidding on provincial or municipal contracts, AODA conformance is increasingly a procurement gate on its own, separate from any formal enforcement action, the same way Section 508 functions as a quiet screening filter in US federal contracting.
The Gap Between "We Did an Audit Once" and Actual Conformance
The most common real-world pattern is an organization that ran a WCAG 2.0 AA remediation project in the run-up to 2021, fixed what the audit found, and never built a process to keep new work conformant afterward. Five years of redesigns, new marketing pages, third-party embedded widgets, and rebuilt checkout flows later, the site that passed in 2021 often does not resemble the site running in production today, and nobody re-tested the difference.
A practical starting point is treating AODA conformance the same way a security team treats a vulnerability scan: not a one-time project with a finish line, but a recurring check tied to release cycles, with WCAG 2.1 AA as the actual bar rather than the technically-minimum 2.0 AA the statute names. Automated scanning catches a meaningful slice of regressions cheaply and continuously; it does not replace a real keyboard and screen reader pass on the pages that actually convert or transact, the same gap that shows up in every WCAG conformance claim that stops at automated tooling.
If your organization has 50 or more employees, is part of Ontario's public sector, or is federally regulated and has not re-tested its website against WCAG since the original AODA push, that gap is worth closing before it shows up in a compliance report, a procurement disqualification, or a complaint. For a broader look at how AODA obligations interact with other accessibility law your organization might also be subject to, our European Accessibility Act guide and Section 508 guide for vendors cover the parallel frameworks in more depth.
Our team can run a free scan against your actual production site, not a sample page, to show exactly where the gap between "we did this once" and current conformance sits. Reach us directly at experts@wcag.world, or start with the official Ontario guidance on making websites accessible and the full text of the regulation if you want to verify any of this against the primary source yourself.
A practical review loop
Start with the task a person needs to complete, not with the score produced by a single automated scan. Write down the entry point, the expected focus order, the announcement a screen reader should receive, and the recovery path when something goes wrong. Then repeat that task with a keyboard and at least one assistive technology setup. This turns a vague accessibility concern into an observable acceptance test.
The useful evidence is specific. Capture the URL, the control label, the keystrokes, the browser state, and the expected result. Separate a defect from a design choice, and separate both from a limitation in the test environment. Give the product owner a short reproduction and a clear severity rationale. A developer can fix a named interaction. Nobody can reliably fix a general instruction to make a page more accessible.
Finally, put the check into the delivery process. Add the scenario to a pull request checklist, retest it after JavaScript changes, and keep a small set of representative pages available for regression testing. That routine protects the people who depend on the workflow and gives the team a defensible record of what was tested, when it was tested, and what happened.
For the next review, use these related resources: request the relevant WCAG review.