WCAG 2.0 Level AA in Plain English: What Ontario Law Actually Requires

AODA doesn’t invent its own accessibility rules — it points straight at WCAG 2.0 Level AA, and that standard is more manageable than it sounds.

What is WCAG, and how does it relate to AODA?

WCAG is the rulebook. AODA is the law that makes following part of it mandatory. This whole article is about the rulebook itself — what practitioners actually do with it day to day is a separate word, a11y, developer shorthand for “accessibility.” Where a11y, WCAG, and AODA each start and stop is its own explainer, if the acronyms themselves are the confusing part.

The Web Content Accessibility Guidelines are written by the W3C’s Web Accessibility Initiative — an international, vendor-neutral standard for making web content usable by people with disabilities. Ontario didn’t write its own version. The Integrated Accessibility Standards Regulation (IASR, O. Reg. 191/11, s.14) — the regulation under AODA — simply names WCAG 2.0 Level AA as the bar public websites have to clear.

Note the version number. The W3C has since published WCAG 2.1 (2018) and 2.2 (2023), each adding more success criteria, mostly around mobile and cognitive accessibility. Ontario’s regulation still cites 2.0. Meeting 2.1 or 2.2 automatically satisfies 2.0 — the versions are backward compatible — but the reverse isn’t true, and the reverse is also all AODA legally requires of you right now.

For the full picture of who this applies to and when, the AODA website accessibility guide covers the whole regulation. This article is just about the standard itself — what it says a website has to do.

What do the four POUR principles actually mean?

POUR breaks accessibility into four plain questions: can someone perceive it, use it, understand it, and will it keep working with whatever assistive technology they’re running?

• Perceivable — information and interface elements have to be presentable in more than one way. Text alternatives for images, captions for video, enough color contrast that text doesn’t disappear against its background.
• Operable — every interactive piece has to work without a mouse. Keyboard navigation, no flashing content that could trigger seizures, enough time to read and act before something times out.
• Understandable — content reads clearly, the site behaves predictably (nav doesn’t move around), and errors get explained in plain language instead of a red border and nothing else.
• Robust — the code itself is clean enough that current and future assistive tech — screen readers, voice control, braille displays — can parse it correctly.

Every one of the 8 common failures further down maps back to one of these four. Contrast and alt text are Perceivable problems. Keyboard traps are Operable. Confusing forms are Understandable. Bad ARIA is a Robust problem in disguise.

What’s the difference between Level A and Level AA?

Level A is the floor — the minimum for a site to function at all with assistive technology. Level AA builds on top of it with the fixes that matter most in everyday use.

Level A criteria include things like: every image has some form of text alternative, every function works from a keyboard, page titles describe the page. Miss these and a screen reader user is often just stuck.

Level AA adds the criteria most people actually notice: minimum color contrast ratios, text that can be resized up to 200% without breaking layout, consistent navigation across pages, visible focus indicators. Level AA conformance requires meeting every Level A criterion too — AA doesn’t replace A, it sits on top of it.

There’s a Level AAA above that — the W3C’s most rigorous tier. AODA doesn’t ask for it, and neither will most of this article. More on why further down.

What does Ontario law actually require, and by when?

Since January 1, 2021, Ontario businesses and non-profits with 50 or more employees — a “large organization” under IASR — must make all their public websites and web content posted after January 1, 2012 meet WCAG 2.0 Level AA. That’s not new-site-only. It’s the whole public-facing site.

The phase-in ran gradually: new websites built after January 1, 2014 had to hit Level A first, with full Level AA becoming mandatory by the 2021 date. There’s a narrow, standard exception carved out of the requirement — WCAG 1.2.4 (live captions) and 1.2.5 (pre-recorded audio description) aren’t legally required, even though doing them anyway is good practice.

Organizations with 20–49 employees file the same accessibility compliance report but are not required to make their website WCAG-conformant under IASR — the report duty and the website duty split at the 50-employee line, which is its own source of confusion. (ontario.ca has the regulation’s website section here.) Under 20 employees, neither obligation applies.

If you’re not sure which bucket your organization falls into, that split deserves a clear-eyed look on its own before you worry about the technical standard — but functionally, if you’re at or approaching 50 employees in Ontario, WCAG 2.0 AA is the bar, full stop.

What are the most common WCAG failures on real business websites?

The same eight problems show up again and again in real audits. None of them require rebuilding the site from scratch.

Why do contrast and keyboard focus trip up so many sites?

Because they’re invisible to whoever built the site with a mouse and a design file. Nobody sets out to break them — they just never get tested the way a low-vision user or a keyboard-only user actually experiences the page.

Contrast fails quietly. A brand palette with light-grey body text on white looks clean in a mockup and fails 4.5:1 in the real world. Designers pick colors for mood; WCAG cares about the ratio between them, measured, not felt.

Keyboard focus fails for a different reason: a lot of developers strip the default browser focus outline in CSS — outline: none — because it clashes with the design, and never replace it. Tab through the page after that and you genuinely can’t tell where you are. Add a JavaScript carousel or a mega-menu that traps focus inside itself, and a keyboard user is stuck until they refresh the page. It’s one of the fastest ways to fail Operable, and one of the easiest to miss if nobody ever unplugs the mouse and tries.

Why does adding ARIA sometimes make a site less accessible?

Because ARIA (the code labels that tell screen readers what an element is) overrides what the browser already knows, and one wrong attribute can tell assistive tech the exact wrong thing about an element.

Take a common pattern: a <div> with an onclick handler, styled to look like a button. Someone adds role=”button” to make it more accessible — but forgets tabindex and a keyboard handler. Now a screen reader announces “button,” but a keyboard user still can’t press it. A plain HTML <button> would’ve given all of that for free, with zero ARIA.

That’s the honest, widely-shared consensus from accessibility practitioners: no ARIA is better than bad ARIA. It applies to hand-written code and it applies just as much to bolted-on accessibility widgets that inject ARIA sitewide without understanding the markup underneath — that’s a separate rabbit hole I’ve covered in the piece on whether an accessibility overlay makes you compliant, and the short answer there is no.

Is my website WCAG compliant?

An automated scanner can tell you your site is not compliant. It can’t tell you it is.

Automated tools are genuinely useful for a first pass — they’ll flag missing alt attributes, contrast failures, and some structural issues fast. But the W3C/WAI consensus, backed by hundreds of accessibility practitioners, is that automated checks catch only a minority of WCAG success criteria. Things like whether link text actually makes sense in context, whether a form’s error messages are understandable, or whether a screen reader user can complete a checkout — none of that shows up in a scanner report. It takes a person testing with a keyboard and assistive technology.

This is also why a $50/month overlay widget claiming to auto-fix WCAG issues doesn’t hold up — automated remediation runs into the same wall as automated auditing. I go deeper on that trap, including the FTC’s $1 million order against one overlay vendor, in the overlay article.

How do you actually check a site for WCAG issues?

With a mix of a scanner for the easy stuff and a human for everything else. That’s the process, roughly, in order:

1. Automated scan first — catches contrast, missing alt text, and some obvious ARIA problems fast.
2. Manual keyboard-only pass — unplug the mouse and Tab through every page, every menu, every form.
3. Screen reader spot-check on the flows that matter most — navigation, forms, checkout — using VoiceOver or NVDA.
4. Heading and landmark structure review — does the page make sense navigated by headings alone?
5. A prioritized fix list ranked by real user impact, not just by how many issues a report flagged.

A retailer in Kitchener or a distributor in Mississauga doesn’t need a release gate built for a national broadcaster, but the underlying habit — test it properly with a keyboard and a screen reader before you call it done — travels just fine to that scale. That habit isn’t theoretical: it’s exactly how Sportsnet.ca’s enterprise migration and Postmedia’s WordPress VIP network of 13+ newspaper blogs ran WCAG checks, as a release gate, not an afterthought, with nothing shipping until someone had actually tabbed through it and listened with a screen reader.

If you’d rather not decode WCAG yourself, that’s the kind of remediation I do — a free scan of your site is a reply away, get in touch.

Do I need Level AAA to be AODA compliant?

No. AODA’s website standard stops at Level AA. Level AAA is the W3C’s most rigorous tier, and it’s not part of the legal requirement for Ontario businesses.

Some AAA criteria are genuinely hard to satisfy for arbitrary content — sign-language interpretation for every video, for instance — and the W3C itself notes AAA isn’t recommended as a general site-wide policy for that reason. Meeting Level AA properly already puts most Ontario businesses ahead of the majority of sites in their sector. Chasing AAA before AA is solid is scope creep nobody asked for.

What should you do with this before December 31, 2026?

If you’re a large Ontario organization — 50+ employees — WCAG 2.0 Level AA isn’t a nice-to-have next to your compliance report. It’s the actual technical bar the law names, and it’s been mandatory since 2021. The report is the paperwork; this standard is the substance behind it.

The AODA website accessibility guide ties the whole regulation together — thresholds, deadline, penalties, plugins-versus-real-fixes. And if you’re already planning to move off an aging WordPress theme, Wix, or Squarespace, remediation is far cheaper folded into that rebuild than bolted on afterward — that’s exactly what I cover in AODA compliance on WordPress, and it’s the kind of work that lives under web design services here.

Frequently asked questions

Quick answers to what Ontario business owners ask most about WCAG 2.0 Level AA.

What is WCAG?

WCAG (Web Content Accessibility Guidelines) is the W3C’s international standard for making web content usable by people with disabilities. It’s organized around four principles — Perceivable, Operable, Understandable, Robust (POUR) — with three conformance levels: A, AA, and AAA.

Is WCAG the same thing as AODA?

No. AODA (Accessibility for Ontarians with Disabilities Act) is the Ontario law. WCAG is the technical standard that AODA’s regulation, the IASR, names for websites — specifically WCAG 2.0 Level AA.

What’s the difference between WCAG 2.0 and WCAG 2.1?

WCAG 2.1 (2018) and 2.2 (2023) add success criteria on top of 2.0, mostly around mobile and cognitive accessibility. Ontario’s AODA regulation still names WCAG 2.0 specifically — that’s the version the law actually requires.

Does my website need to meet Level AAA to be AODA compliant?

No. AODA’s website requirement is WCAG 2.0 Level AA. Level AAA is the W3C’s most demanding tier and isn’t part of the Ontario legal requirement.

Does an accessibility overlay make my website WCAG compliant?

No. Automated overlay widgets catch only a minority of WCAG success criteria and can’t achieve full conformance — that’s the widely-held W3C/WAI position, and it’s also the basis for the FTC’s $1 million order against one overlay vendor in 2025.

What’s the minimum color contrast ratio for WCAG 2.0 Level AA?

4.5:1 for normal text, and 3:1 for large text (roughly 18pt, or 14pt bold). It’s the single most commonly flagged failure in real accessibility audits.