AODA Website Accessibility: The Complete Ontario Business Guide

Here’s the complete, no-fluff breakdown of what AODA actually requires from an Ontario business website — who it binds, what WCAG 2.0 AA demands, and why December 31, 2026 matters more than most owners think.

What is AODA, and does it actually apply to my business?

AODA is the Accessibility for Ontarians with Disabilities Act, Ontario’s provincial law (S.O. 2005, c.11) that sets accessibility standards for businesses and organizations on a schedule the province controls. Yes, it applies to you. Almost certainly. What changes hard is exactly what it demands, and that scales directly with how many people you employ in Ontario.

Everything in this guide sorts into one of three buckets: the law (AODA), the standard behind it (WCAG), and the daily practice of actually meeting both, which most developers just call a11y. The full acronym breakdown is worth five minutes if you want the short version before the details below.

Sportsnet.ca — the enterprise media migration I worked on — got accessibility-audited before launch, full stop, because a national broadcaster cannot afford a lawsuit over an unlabeled form field or a contrast ratio nobody checked. That’s the discipline behind this guide, not a compliance consultant reading you a regulation from the sidelines. A 20-person retailer in Kitchener will never face that scale of scrutiny, but the underlying discipline doesn’t change with the size of the business, and the law doesn’t ask a small business to build what Sportsnet built. Small does not mean exempt, though, and untangling exactly where that line sits is the whole point of this guide.

So here’s the map. Who AODA actually binds, tier by tier. The December 31, 2026 deadline and what it does and doesn’t require of you. What WCAG 2.0 Level AA means in plain terms. What an accessible site concretely needs. Why the overlay widget you’ve probably been pitched won’t get you there. What non-compliance actually costs. And how to fix this properly, once, instead of paying for it twice.

Does AODA apply to small business? (The employee-count thresholds)

Yes — but what it requires of you depends entirely on how many employees you have in Ontario, and there are three distinct tiers. Get this table wrong and you’ll either panic over nothing or miss a real legal duty.

Under the Integrated Accessibility Standards Regulation (IASR), a “large organization” is defined as one with 50 or more employees in Ontario; a “small organization” is 1–49. Notice what that table actually says once you sit with it: a 35-person marketing shop and a 60-person manufacturer both have to file the exact same report by the same deadline. Only the manufacturer is legally on the hook for the website itself. That single distinction confuses more Ontario business owners than anything else in this law — enough that it gets its own breakdown, with worked examples, in does AODA apply to small business, including how to count your Ontario headcount correctly.

What is the AODA 2026 deadline, and do I have to file anything?

If you employ 20 or more people in Ontario, yes: your accessibility compliance report is due December 31, 2026, filed through the Accessibility Compliance Reporting Portal. Miss that date and you’re not late on paperwork — you’re non-compliant with a statutory deadline, which is where the enforcement chain below starts.

Per Ontario’s official guidance on completing your accessibility compliance report, private and non-profit organizations file every three years. Designated public sector organizations file every two years, and their last report was due December 31, 2025. If you’re under 20 employees, there’s nothing to file at all — but keep reading, because that doesn’t mean nothing applies to you.

Twenty-something months sounds like a lot of runway until you actually try to schedule an accessibility audit, fix what it finds, document your policies, and then file. The step-by-step version of exactly what changes and what the portal asks for lives in the dedicated 2026 deadline explainer.

What’s the difference between filing the report and making my website accessible?

Filing the compliance report is a paperwork obligation — you’re attesting that you’re aware of and following AODA’s policy, training, and customer-service requirements. Making your website conform to WCAG 2.0 AA is a separate, harder, and far more expensive duty that only becomes legally mandatory once you cross 50 employees in Ontario.

Walk through the two examples from the table above one more time, because this is the part that trips people up in real conversations I have with clients. A 35-person agency has to file the report by December 31, 2026 — full stop, no exceptions. But the law itself does not force that agency to remediate its website’s contrast ratios or fix its keyboard navigation. A 60-person manufacturer files the identical report and its website is legally required to hit WCAG 2.0 AA, with documented policies posted publicly and a multi-year accessibility plan behind it.

Here’s the honest caveat, though. “Not legally required” is not the same as “no reason to.” Accessibility lawsuits and demand letters in North America don’t check your employee count before they land, and a growing share of them target sites that installed a quick-fix widget and called it done — more on that shortly. For the full worked-example breakdown of exactly where your business sits, see the employee-thresholds guide.

What accessibility standard does Ontario law actually require?

WCAG 2.0 Level AA — note the version number carefully, because it’s 2.0, not the newer 2.1 or 2.2 you’ll see referenced elsewhere. This comes straight from the IASR, specifically Ontario Regulation 191/11, section 14.

For large private-sector organizations, the phase-in ran over several years. New websites had to meet Level A starting January 1, 2014. Full Level AA has been mandatory for all public-facing content since January 1, 2021. If your site went live any time in the last five years and nobody mentioned WCAG during the build, there’s a decent chance it never actually cleared that bar. There’s one standard statutory exception worth knowing: the requirement excludes success criteria 1.2.4 (live captions) and 1.2.5 (audio description).

WCAG itself isn’t Ontario law — it’s an international technical standard from the W3C that Ontario adopted wholesale as its legal benchmark. Understanding it in plain English, not spec-document English, is worth its own guide: see WCAG 2.0 Level AA explained for Ontario businesses.

How do I know if my website is AODA compliant?

There’s no government badge or certificate to check for — compliance means your site actually conforms to WCAG 2.0 AA’s success criteria, and that only gets confirmed through real testing, not a glance at the homepage.

Start with a handful of checks you can genuinely run yourself this week. Tab through your entire homepage using only your keyboard — no mouse — and see whether you can reach and activate every link, button, and form field, and whether you can always tell where focus currently sits. Run a contrast checker against your body text and your buttons. Try navigating your top five pages with a screen reader, even just VoiceOver on a Mac, and listen to how much of it actually makes sense read aloud. Check every form field for a real, programmatically-linked label.

Automated scanners like Lighthouse, axe, or WAVE are a decent first pass, and I run them on every audit I do. But they’re a first pass only — the honest number floating around the accessibility field is that automated tools catch a minority of real WCAG issues, and the rest only surface under manual testing with actual assistive technology. That gap is exactly what a lot of “AODA compliance” tools quietly gloss over, and it’s worth understanding before you buy anything.

What makes a website accessible? (POUR, explained)

WCAG organizes every single requirement under four principles, and the W3C’s Web Accessibility Initiative uses the acronym POUR to teach it: Perceivable, Operable, Understandable, Robust.

Perceivable

Users have to be able to perceive your content through at least one sense, even if they can’t use another. Alt text for images, captions for video, sufficient color contrast — all of it exists so information doesn’t depend on a single sense working perfectly.

Operable

Every interactive element has to be usable without a mouse, without a fixed time limit that’s too tight, and without anything that flashes in a way that could trigger a seizure. Keyboard operability is the big one here, and it’s the one I see fail most often.

Understandable

Content and interface behaviour need to be predictable. Clear labels, consistent navigation, form errors that actually explain what went wrong instead of a vague red asterisk.

Robust

Your markup has to be solid enough that a wide range of tools — screen readers, browser extensions, future technology nobody’s built yet — can reliably interpret it. Clean, semantic HTML wins here every time.

Every one of the failures in the next section maps back to one of these four buckets, which is exactly why WCAG structures itself this way. It’s not an arbitrary checklist — it’s a framework.

What are the most common website accessibility failures?

The same handful of issues show up on almost every site I’ve looked at, long before I ever get to anything exotic. Fix these eight and you’ve closed most of the gap.

• Missing or poor alt text. Images with no alt attribute, or alt text that just says “image123.jpg.”
• Low color contrast. The single most-flagged issue across the industry. WCAG AA requires at least 4.5:1 for normal text and 3:1 for large text, and a lot of “on-brand” light-gray-on-white designs fail this outright.
• Keyboard inaccessibility. Elements you can only reach with a mouse, or invisible/trapped keyboard focus that leaves a user stuck inside a menu or modal with no way out.
• Unlabeled form fields. A placeholder is not a label. Screen readers need a real, linked label to announce what a field is for.
• Ambiguous link and button names. A page full of “click here” links, or icon-only buttons with no accessible name, tells a screen reader user nothing about where they’re about to go.
• Broken heading structure. Headings used for visual size instead of document structure, or skipping straight from an H2 to an H4, breaks the outline assistive tech relies on to navigate.
• ARIA misuse. Bolted-on ARIA (the code labels that tell screen readers what an element is) that contradicts the actual markup. The accessibility community has a saying for this: no ARIA is better than bad ARIA.
• Media without captions. Video and audio content with no captions or transcript, locking out anyone who’s deaf or hard of hearing, or just watching on mute.

Fix examples for each of these, with real before-and-after code, live in the WCAG 2.0 AA explainer.

Does an accessibility overlay or widget make my website compliant?

No. And regulators have started proving that in public, not just accessibility advocates arguing about it online.

In January 2025 the FTC filed a complaint against accessiBe, and in April 2025 finalized an order requiring the company to pay $1,000,000 for falsely claiming its accessWidget could make any website WCAG-compliant, and for disguising paid reviews as independent ones (FTC press release). That’s a federal regulator putting a dollar figure on exactly the claim most overlay vendors still make in their sales copy.

The lawsuit data backs it up. UsableNet’s 2025 year-end report counted more than 5,000 digital-accessibility lawsuits filed that year, roughly 70% against e-commerce sites, and a growing share of them were filed against sites that already had an overlay or widget installed when they got sued. The W3C’s Web Accessibility Initiative and the practitioner-signed Overlay Fact Sheet — more than 900 accessibility professionals put their names on it — reach the same conclusion: automated overlays cannot achieve full WCAG conformance, they catch only a minority of real issues, and manual testing with actual assistive technology is not optional.

Here’s the honest take, and I’ll say it plainly because most owners never hear it from the people selling them the widget. A lot of Ontario SMEs are being sold a $50-a-month script that does not make them compliant and, per that lawsuit data, may actually raise their legal exposure by advertising an accessibility claim the site can’t back up. This is exactly the wedge topic I go deep on in why an accessibility overlay doesn’t make your site AODA compliant, including the full breakdown of why bolted-on scripts can leave a site worse off than doing nothing.

What happens if my business doesn’t comply with AODA?

Real fines, and they compound daily — under the AODA (S.O. 2005, c.11, s.37), a corporation can be fined up to $100,000 per day, an individual up to $50,000 per day, and directors or officers can be held personally liable up to $50,000 per day. That last one matters: the law puts a duty on directors and officers to take reasonable care to prevent an offence, so “the company handles that” isn’t a shield.

Offences include furnishing false or misleading information in a compliance report, or failing to comply with an order from a director. The enforcement path runs in a fairly predictable sequence: the report itself is the trigger, followed by director follow-up, then formal orders, and only then prosecution if nothing’s fixed — with appeals available through the License Appeal Tribunal.

Notice what that sequence actually rewards. Businesses that respond honestly when a gap gets flagged rarely end up at the prosecution stage. The ones that ignore a director’s order, or fudge a report to look compliant when they aren’t, are the ones who end up doing the math on “per day.”

How do I actually make my website AODA compliant?

Treat it as a real engineering project, not a checkbox on a vendor’s pricing page. That means testing against the actual standard, fixing the code, and documenting what you did — in that order.

1. Run a real audit

Combine automated scanning (Lighthouse, axe, WAVE) with manual testing: keyboard-only navigation, a screen reader pass, and a contrast check against every text/background pairing on the site. This is where you find out how far off WCAG 2.0 AA you actually are, not how far off you assume you are.

2. Fix the code, don’t bolt on a script

Alt text, contrast, labels, heading structure, and keyboard traps get fixed in the markup and CSS, not papered over by a widget injected via a script tag. This is the part an overlay cannot do for you, no matter what the sales page says.

3. Document and post your policies (50+ employees)

If you’re a large organization, your accessibility policies need to be written down, publicly posted, and backed by a multi-year accessibility plan — not just practiced informally.

4. File the compliance report on time

Twenty or more employees means the report is due December 31, 2026, through the Accessibility Compliance Reporting Portal, regardless of whether your website duty applies.

If you’d rather not decode WCAG yourself line by line, that’s the kind of remediation I do for a living. The free scan is an automated pass plus a manual keyboard-and-screen-reader spot check of your key pages, back to you within a few days as a plain-English punch list — and real remediation typically costs less than a couple of years of an overlay subscription. Reach out and I’ll tell you where your site stands.

Should I fix accessibility during a redesign or migration?

Yes, without question — a redesign or migration is the cheapest point in a site’s entire lifespan to build accessibility in properly, because you’re already touching every template and every piece of markup.

Remediating an existing site means going page by page, fixing code that’s already live and already load-bearing for your business. Building it in during a rebuild means the contrast ratios, the semantic headings, and the keyboard behaviour are just how the new site is built from day one — no separate remediation pass required afterward. If you’re already planning to move off Wix or Squarespace, or you’re doing any kind of WordPress migration, fold the accessibility work into that same project instead of treating it as a second, separate expense down the road.

This matters even more if WordPress is your stack, because a lot of what ships in popular themes and page-builder plugins is quietly inaccessible out of the box — see AODA compliance and WordPress for exactly where that breaks and how a properly built site avoids it entirely.

When should I hire someone to handle AODA compliance for me?

The moment you cross 50 employees, or the moment December 31, 2026 is close enough that a DIY audit-and-fix cycle no longer fits your runway, hiring a professional stops being optional and starts being the cheaper path.

Scale is where I’ve learned this lesson the hard way, more than once. I worked on migrating Postmedia’s network of 13-plus newspaper blogs onto WordPress VIP — every title on different legacy software, all of it needing to clear VIP’s own accessibility and quality bar before it could ship. And on the Scattergood Foundation migration, the accessibility-adjacent work was in the taxonomy and redirects: a large archive of legacy research publications, each belonging to multiple classifications at once, all needing to land on WordPress without breaking the structure a reader — or a screen reader — depends on to find anything. You don’t get that judgment from a tutorial. You get it from getting bitten on projects where the wrong call would have cost someone their archive.

A Cambridge manufacturer or a Mississauga distributor doesn’t need Postmedia-scale infrastructure. But the same discipline — real testing, real code fixes, no shortcuts dressed up as compliance — applies at any size. That’s exactly what jbe.works Web Design builds in from the ground up. If you want a second opinion on where your current site actually stands, reach out and I’ll tell you straight.

Your next step

Here’s the whole shape of it. Know your number first: figure out which tier you’re actually in — under 20, 20–49, or 50+ — because that single number decides whether you owe a report, a website, or both. If you’re at 20 or more employees, mark December 31, 2026 on the calendar now, and hold the line on the standard itself — WCAG 2.0 Level AA, not 2.1, mandatory for large private organizations since January 1, 2021. Do not let anyone sell you a widget as a finished answer — the FTC already fined one vendor $1,000,000 for making that exact claim.

From here, go deep wherever your business actually sits. Nail down your exact tier in the employee-thresholds guide. Get the full deadline mechanics in the 2026 deadline explainer. Understand the standard itself in WCAG 2.0 AA explained. See exactly why overlays fail in the overlay compliance breakdown. And if WordPress is your stack, AODA compliance and WordPress covers the platform-specific traps. If the acronyms themselves are what’s confusing, the piece that untangles a11y, WCAG, and AODA sorts out which one’s the practice, which one’s the standard, and which one’s the law. If you’d rather have someone who’s done this on enterprise builds handle it properly, jbe.works Web Design is built around exactly that.

Frequently asked questions

Quick, direct answers to the questions I hear most.

Does AODA apply to small business?

Yes, in a limited way. Under 20 employees, you owe no report and no website conformance, though customer-service and training rules still apply. At 20–49 employees you must file a compliance report every three years, but your website is not legally required to meet WCAG.

Is my website AODA compliant?

Only if it’s been tested against WCAG 2.0 Level AA using both automated scanning and manual testing with real assistive technology — keyboard navigation, a screen reader pass, and contrast checks. There’s no official badge; compliance means the site actually passes the standard.

Does an accessibility overlay make my site compliant?

No. The FTC fined accessiBe $1,000,000 in 2025 for falsely claiming its overlay widget could make any site WCAG-compliant, and 2025 saw 5,000-plus digital accessibility lawsuits, a growing share against sites that already had an overlay installed.

What is the AODA deadline for 2026?

December 31, 2026 is when businesses and non-profits with 20 or more employees in Ontario must file their accessibility compliance report through the Accessibility Compliance Reporting Portal.

What is WCAG 2.0 Level AA?

It’s the specific accessibility standard Ontario law requires under the IASR — note it’s version 2.0, not 2.1. Large private organizations have needed full Level AA conformance since January 1, 2021, with a narrow exception for live captions and audio description.

What happens if I don’t comply with AODA?

Fines up to $100,000 a day for a corporation, up to $50,000 a day for an individual, and directors or officers can be personally liable up to $50,000 a day. Enforcement runs from the report, to director follow-up, to formal orders, to prosecution.