AODA Compliance: What Ontario Businesses Must Do for Web Accessibility

AODA is Ontario's accessibility law. The technical detail lives in a regulation under it: the Integrated Accessibility Standards Regulation (IASR, O. Reg. 191/11), which bundles standards for Information and Communications, Employment, Transportation, and the Design of Public Spaces.

Web accessibility sits inside the Information and Communications Standard. That standard requires covered organizations to make their internet websites and web content conform to the WCAG 2.0 Level AA success criteria. So when people say "AODA compliance" for a website, they really mean WCAG 2.0 AA conformance, with two specific exceptions noted below.

The website obligation is scoped by sector and headcount, so it does not apply equally to everyone:

• Public-sector organizations (the Ontario government, agencies, municipalities, school boards, colleges, universities, hospitals): covered regardless of size.
• Large private and non-profit organizations with 50 or more employees in Ontario: fully covered by the WCAG 2.0 AA website requirement.
• Small organizations with fewer than 50 employees: exempt from the formal WCAG 2.0 AA website requirement and from accessibility reporting, but still bound by other AODA duties such as accessible customer service and providing accessible formats on request.

Headcount is the trigger most businesses get wrong. The 50-employee threshold counts employees in Ontario, including part-time and seasonal staff. If your store recently crossed 50 people, the website requirement applies to you now, not at some future date.

AODA references WCAG 2.0 Level AA specifically, with two carve-outs: you are not required to provide live captions (1.2.4) or prerecorded audio description (1.2.5). Everything else at Level A and AA applies. Here is what that means for a real website:

• Color contrast (1.4.3): body text needs a ratio of at least 4.5:1 against its background; large text (18pt, or 14pt bold) needs 3:1. A free contrast checker catches these in seconds.
• Text alternatives (1.1.1): every meaningful image needs alt text, and decorative images need empty alt attributes so screen readers skip them.
• Keyboard access (2.1.1): menus, dropdowns, modals, and your entire checkout must work without a mouse. This is where most ecommerce sites fail.
• Forms and labels (3.3.2, 1.3.1): every input needs a programmatically associated label, and errors must be described in text, not color alone.
• Page structure (1.3.1, 2.4.6): real heading hierarchy, landmark regions, and descriptive link text, not a wall of "click here."

A note on versions: WCAG 2.1 and 2.2 AA are backward-compatible supersets of 2.0, so building to 2.1 or 2.2 AA satisfies AODA's 2.0 AA baseline while preparing you for stricter regimes such as the European Accessibility Act and EN 301 549 if you sell into the EU. WCAG 2.2 adds criteria like target size (24x24 CSS pixels) and accessible authentication that genuinely improve usability, so newer is the safer default.

This is the part Ontario businesses most often misunderstand. The major web deadline is in the past, not the future.

• 1 January 2021: large private and non-profit organizations (50+ employees) and all public-sector bodies must make their websites and web content conform to WCAG 2.0 Level AA.
• Ongoing: the requirement is continuous. Every new page, blog post, campaign landing page, or PDF you publish must meet the standard, not just the site you had in 2021.
• Periodic reporting: designated public-sector organizations and large private and non-profit organizations file accessibility compliance reports with the province on a recurring basis.

In other words, there is no grace period left to wait out. If you are over the threshold and your site is not conformant, you are already non-compliant.

AODA is backed by administrative penalties that the Ontario government can levy, and directors and officers can be held accountable. Beyond formal enforcement, the everyday costs are usually larger: accessibility complaints, customers who abandon an unusable checkout, procurement contracts you cannot win because you cannot demonstrate conformance, and rushed remediation under deadline pressure.

Keep claims defensible and keep records. A documented audit, a remediation log, and a published multi-year accessibility plan are what regulators and partners actually want to see.

You do not need to fix everything at once. Work in priority order, starting with the barriers that block the most users on your highest-traffic pages.

1. Scan to find your real barriers

Start with an automated baseline. Run your homepage, a key landing page, and your checkout through a free accessibility scan to surface contrast failures, missing alt text, unlabeled form fields, and broken heading structures. Automated tools reliably catch roughly a third to half of WCAG issues, which makes them the right first pass, not the last word.

2. Manually test what tools cannot

Tab through every page with only your keyboard. Can you reach and operate the menu, the cookie banner, the modal, the Add to Cart button, and complete a purchase? Then test with a screen reader. Use the accessibility checklist to keep coverage consistent across the team.

3. Fix in priority order

Triage by impact: keyboard traps and an inaccessible checkout come before a contrast tweak on a footer link. Bake fixes into your templates and components so new pages inherit accessibility instead of repeating the same mistakes.

4. Publish an accessibility statement and keep records

Document your conformance status, known issues, and how users can request accommodations or report barriers. A free accessibility statement generator gives you a defensible starting point. Pair it with a multi-year plan and re-scan after every significant release, since accessibility regresses the moment new code ships.