A lot of Ontario businesses add an "Accessibility Statement" page to their website, link it in the footer, and quietly assume the box is checked. It isn't. A statement is a piece of text about your website's accessibility — it does nothing to the underlying code that a person using a screen reader or keyboard actually encounters. Worse, a statement that claims a level of accessibility you haven't reached can become evidence against you rather than protection. Here's what the AODA (Accessibility for Ontarians with Disabilities Act) and WCAG (Web Content Accessibility Guidelines) actually require — and where a statement fits.
Key facts
- Ontario's IASR (Integrated Accessibility Standards Regulation, O. Reg. 191/11) — the regulation under the AODA — requires every obligated organization to develop and maintain accessibility policies (s.3(1)) (ontario.ca / e-Laws).
- Organizations with 50 or more employees ("large organizations") must include a statement of organizational commitment in those policies, put the policies in writing, and make them publicly available (IASR s.3(2)–(3)) (ontario.ca / O. Reg. 191/11).
- Organizations with 1–49 employees ("small organizations") must still develop policies, but are not required to put them in writing or post them publicly (IASR definitions + s.3).
- The W3C (World Wide Web Consortium) does not require a website to publish a conformance claim — but if you do make one, it must state the date, the WCAG version and URL, the conformance level (A, AA, or AAA), the pages covered, and the technologies relied upon (W3C / WAI, "Making Your Website Accessible").
- None of these documents change what your site does: under IASR s.14, public websites of large organizations must conform to WCAG 2.0 Level AA — a separate, technical obligation that no statement satisfies on its own.
- The next ACR (Accessibility Compliance Report) deadline for private-sector organizations and non-profits with 20 or more employees is December 31, 2026 (ontario.ca).
What does Ontario's AODA actually require — a statement, or an accessible site?
Both, but they are two different things, and people routinely confuse them.
The legal document. The IASR (s.3) requires obligated organizations to have accessibility policies describing how they meet their AODA obligations. For large organizations (50+ employees), those policies must include a statement of organizational commitment to meeting the accessibility needs of people with disabilities in a timely manner, must be written, and must be publicly available and provided in an accessible format on request. This is an internal governance document you publish — it sits alongside your multi-year accessibility plan, which is a separate IASR requirement.
The technical obligation. Completely separately, IASR s.14 requires the website itself of a large organization to conform to WCAG 2.0 Level AA. That is about code: alt text, keyboard operability, colour contrast, form labels, focus order. A policy document, however well written, does not produce a single one of those fixes.
So "do I need an accessibility statement?" is the wrong question. The law asks whether your policy exists (and is public, if you're 50+) and whether your site actually conforms. A statement page is neither — it's an optional, best-practice courtesy that describes the second thing.
Is a website accessibility statement the same as the AODA accessibility policy?
No — and treating them as interchangeable is where businesses get exposed.
A website accessibility statement is a public-facing page, recommended by the W3C's WAI (Web Accessibility Initiative) as good practice. At its best it tells a disabled visitor: what standard you aim for, how to report a barrier, what you already know isn't fixed yet, and who to contact. The W3C even publishes a free statement-generator tool, and is explicit that conformance claims are optional and should use plain language people can understand.
The AODA accessibility policy is the regulatory document under IASR s.3 described above. The two can reference each other, but a generic statement copied off a template does not satisfy the IASR policy requirement, and the IASR policy does not satisfy WCAG.
The trap is the third thing both are mistaken for: an accessible website. A statement is a label on the tin; the policy is a promise about the tin; only real source-code remediation changes what's inside. This is the same gap that makes accessibility overlays a poor substitute — a widget bolted onto the page doesn't rewrite the underlying barriers any more than a paragraph in the footer does.
Can an accessibility statement actually create legal risk?
It can, if it overclaims. This is worth being precise — and not alarmist — about.
The W3C is clear that a conformance claim must be accurate: a real date, a real version, a real conformance level, an honest description of which pages conform. A statement that asserts "this website is fully WCAG 2.1 AA compliant" or "fully accessible" when it demonstrably isn't is a misrepresentation about your own site, published in your own words. In an HRTO (Human Rights Tribunal of Ontario) complaint under the Ontario Human Rights Code, or an ADA (Americans with Disabilities Act) claim if you sell to US customers, what a person with a disability could actually do on your site is what gets tested — and your public claim is part of the record a complainant can point to.
The same logic landed an overlay vendor in trouble with the US FTC (Federal Trade Commission), which acted against accessibility claims it found unsupported. The lesson scales down: don't publish an accessibility claim your site can't back up. An honest statement that says "we're working toward WCAG 2.1 AA and here's how to report a problem" is safer than a confident one that's false.
What should an Ontario business do — write the statement, or fix the site first?
Fix first, claim second. In order:
- Find out where your site actually stands. A real evaluation against WCAG — not a label — tells you what conforms and what doesn't. A scan flags machine-detectable issues; a full audit catches the rest.
- Remediate in the code. Fix the barriers at the source so the claim you eventually make is true.
- Write the IASR policy (and post it publicly if you have 50+ employees), including the statement of organizational commitment the regulation requires.
- Then publish an honest website accessibility statement — target standard, contact for barriers, known limitations, last-reviewed date — using plain language as the W3C recommends.
- Keep a dated record of the remediation work. That documented record, not the statement, is what holds up if a complaint is ever tested.
Whether you owe the written, public policy at all depends on your headcount — the line sits at 20 vs 50 employees in Ontario.
See where your site actually stands in about 30 seconds — free Vayle Report: vayle.art. It detects overlays, shows real WCAG failures, and tells you exactly what legally applies to your organization in Ontario. No obligation.
Vayle is a remote-first accessibility-engineering studio serving Ontario. General information, not legal advice.