Aoda Training

What Is WCAG? A Plain-Language Guide for Ontario Businesses

WCAG — Web Content Accessibility Guidelines — is the international standard that defines what it means for a website to be accessible. For Ontario businesses, it matters because AODA requires websites to meet WCAG 2.0 Level AA. This guide explains exactly what that means, without jargon.

93% Student Satisfaction (2K ratings)

Quantity Discounts

Price per course

6 to 20 courses

$20.95

21 to 50 courses

$17.95

51 to 200 courses

$13.95

201+ courses

Custom offer

WCAG stands for Web Content Accessibility Guidelines. It is an international standard that defines what it means for a website to be accessible to people with disabilities. For Ontario businesses, it matters because provincial law — the Accessibility for Ontarians with Disabilities Act — requires websites to meet WCAG 2.0 Level AA. If someone has told you your website needs to be WCAG compliant, this guide explains what that means in plain language.

WCAG is published by the World Wide Web Consortium (W3C), the international body that sets web standards. It is not a Canadian or Ontario-specific document — it is used globally as the benchmark for accessible web content. Ontario’s AODA adopted it as its technical standard because it is the most comprehensive and widely recognized framework for web accessibility that exists.

WCAG is a technical standard, not a law

WCAG itself is not a law. It is a technical specification published by an international standards body. What makes it legally significant for Ontario organizations is that AODA's Information and Communications Standard incorporates WCAG 2.0 Level AA by reference — making it the legal benchmark your website must meet. The law is AODA; the technical yardstick the law uses is WCAG.

🏛️

Who created WCAG and why

The Web Content Accessibility Guidelines were first published in 1999 by W3C’s Web Accessibility Initiative (WAI). The goal was to create a single, testable international standard that governments, organizations, and developers could use to evaluate and improve web accessibility.

WCAG 2.0 was published in 2008 and became the global reference point. It was designed to be technology-neutral — the guidelines apply to HTML, CSS, JavaScript, PDFs, and any web-based content regardless of the platform or programming language used to create it.

🎯

The three WCAG conformance levels: A, AA, and AAA

WCAG organizes its success criteria into three levels of conformance. Each level builds on the previous one.

Level What it represents AODA requirement? Practical reality
Level A Minimum accessibility. Addresses the most fundamental barriers — issues that make content completely inaccessible to some users. Yes — Level AA includes all Level A criteria A site that only meets Level A still has significant barriers. Meeting Level A alone is not sufficient for AODA compliance.
Level AA Standard accessibility. Addresses the most significant remaining barriers after Level A. The level at which most organizations can realistically achieve compliance. Yes — this is what AODA requires The practical target for all Ontario websites. Meeting Level AA means meeting all 38 Level A and AA criteria combined.
Level AAA Enhanced accessibility. The most specific and demanding requirements. Not all content can meet Level AAA. No — AODA does not require Level AAA W3C itself recommends not requiring Level AAA as a general policy, as it is not achievable for all content.
When Ontario’s AODA says your website must “conform to WCAG 2.0 Level AA,” it means your site must meet all 38 success criteria at Level A and Level AA combined. Conformance is pass/fail against each individual criterion — there is no partial credit.
📋

The most important WCAG 2.0 Level AA criteria in plain language

WCAG 2.0 has 25 Level A criteria and 13 additional Level AA criteria — 38 in total. Here are the most commonly tested and most frequently failed, written in plain language with real pass/fail examples.

Perceivable: content users can sense

1.1.1
Level A
Images must have text alternatives
Every image that conveys information must have alt text — a text description that conveys the same meaning. Decorative images must use empty alt text (alt="") so screen readers skip them.
✓ Pass
A chart showing quarterly revenue has alt text: "Bar chart: Q4 revenue up 12% year-on-year."
✗ Fail
The same chart has alt="chart.png" or no alt attribute at all.
1.2.2
Level A
Pre-recorded video must have captions
All pre-recorded video with audio must have synchronized, accurate captions. Auto-generated captions do not pass without human review and correction.
✓ Pass
A product demo video has reviewed captions matching the spoken content, including speaker identification.
✗ Fail
The same video uses unchecked auto-captions, producing multiple errors throughout.
1.3.1
Level A
Visual structure must be in the code, not just the design
Information conveyed through visual structure — headings, lists, tables, form labels — must be in semantic HTML markup so assistive technologies can interpret it.
✓ Pass
Section titles use proper <h2> and <h3> heading elements. Bullet points use <ul>/<li>.
✗ Fail
Section titles are styled <div> elements made to look bold and large with CSS, with no heading markup.
1.4.3
Level AA
Text must have sufficient colour contrast
Normal text must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt+ or 14pt+ bold) requires at least 3:1. This is the single most commonly failed WCAG criterion.
✓ Pass
Dark grey body text (#333333) on white achieves approximately 12.6:1 — well above the minimum.
✗ Fail
Light grey text (#999999) on white achieves approximately 2.8:1 — fails for normal-sized text.

Operable: interface users can control

2.1.1
Level A
Everything must work by keyboard
All functionality — every link, button, form, dropdown, modal, date picker, and interactive element — must be reachable and operable using a keyboard alone. No mouse required.
✓ Pass
A dropdown menu opens on Tab focus and items are selectable with Enter or arrow keys.
✗ Fail
The same dropdown only opens on mouse hover, making it unreachable for keyboard-only users.
2.4.1
Level A
Users can skip repeated navigation
A mechanism must exist to allow users to skip past repeated navigation blocks. Typically a "Skip to main content" link at the top of every page.
✓ Pass
A visually hidden skip link appears at the top of each page and becomes visible on keyboard focus.
✗ Fail
No skip link exists, forcing keyboard users to Tab through the entire navigation on every page load.
2.4.6
Level AA
Headings and labels must be descriptive
Headings must describe the section that follows. Form labels must describe expected input. Generic headings ("Section 1") and vague labels ("Enter here") fail.
✓ Pass
A section heading reads: "AODA compliance deadlines by organization size."
✗ Fail
The same section is headed "Section 3" or "More information."
2.4.7
Level AA
Keyboard focus must be visible
When navigating by keyboard, the focused element must have a visible indicator — a focus ring or highlight. Removing focus outlines in CSS without an alternative fails this criterion.
✓ Pass
Interactive elements show a visible blue outline when focused via keyboard.
✗ Fail
All focus outlines are removed with outline:none in CSS, making keyboard position invisible.

Understandable: content and behaviour users can predict

3.3.1
Level A
Form errors must be identified in text
When a form error occurs, the error must identify which field failed and describe the problem in text — not by colour alone.
✓ Pass
An invalid email field shows: "Email address — Please enter a valid email address (e.g. name@example.com)."
✗ Fail
The email field border turns red with no text explanation. Users with colour blindness may not perceive the error.
3.3.2
Level A
Form fields must have visible labels
All form fields must have a persistent visible label describing the expected input. Placeholder text inside a field disappears when the user starts typing and does not satisfy this criterion.
✓ Pass
A field has a persistent label above it: "Email address" with the input field below.
✗ Fail
The field shows only placeholder text "Enter your email" inside the field, which vanishes when clicked.

Robust: code assistive technologies can interpret

4.1.2
Level A
All UI components must have a name, role, and value
Every interface component — buttons, inputs, custom widgets — must have a name (what it is called), role (what type it is), and value (current state) that assistive technologies can read programmatically.
✓ Pass
A custom toggle uses < button role="switch" aria-checked="true"> with a visible label and is announced correctly by screen readers.
✗ Fail
The same toggle is a styled < div > with no ARIA. A screen reader cannot determine what it is, what it does, or whether it is on.
⚖️️

How WCAG connects to AODA: four common misconceptions

Our website accessibility services cover the full compliance journey — from initial assessment through remediation, testing, and ongoing monitoring. Each service is scoped to your organization’s size, technology, and compliance timeline.

Misconception The reality
"If we meet WCAG, we are AODA compliant." WCAG addresses your website obligations under the Information and Communications Standard. Full AODA compliance also requires staff training, accessible policies, employment practices, and accessible formats on request. WCAG is one component of AODA, not the whole of it.
"WCAG is optional — it is just a guideline." WCAG is a guideline document, but AODA makes it a legal requirement for Ontario websites. Calling it optional because it has "guidelines" in the name misunderstands the legal structure. The law requires it.
"We have a high Lighthouse score, so we are WCAG compliant." Google Lighthouse uses a subset of WCAG checks to generate a score. A score of 95/100 does not mean WCAG 2.0 Level AA compliance. Manual testing and screen reader evaluation are required for a genuine compliance assessment.
"Our overlay tool makes us WCAG compliant." Accessibility overlay products do not produce WCAG compliance. They have been widely rejected by accessibility specialists and disabled users. Genuine compliance requires fixing the underlying code and content.
👥

Who in your organization needs to understand WCAG

WCAG is not just for web developers. Different roles need different levels of understanding to keep a website accessible as it evolves.

Role What they need to know
Web developers and front-end engineers All 38 Level AA criteria in technical detail — how to implement them in HTML, CSS, ARIA, and JavaScript, and how to test using axe, NVDA, and keyboard navigation.
UX and visual designers Colour contrast requirements, focus indicator design, touch target sizing, accessible component patterns, and how to annotate designs for accessible implementation.
Content writers and editors How to write alt text, use heading structure correctly, write descriptive link text, create accessible documents, and produce accurate captions for video content.
Marketing and communications managers What WCAG requires for campaign content, email marketing, social media, and digital advertising — enough to brief and approve content correctly.
Senior management and directors What WCAG 2.0 Level AA compliance requires at an organizational level, the legal risk of non-compliance, and how to resource a compliance programme appropriately.

Frequently asked questions

What does WCAG stand for?
  • WCAG stands for Web Content Accessibility Guidelines. It is pronounced “wuh-kag” by most accessibility professionals. It is published by the World Wide Web Consortium (W3C) and is the international standard for web accessibility used by governments, organizations, and developers worldwide.
  • WCAG 2.1 adds 17 new success criteria to the 38 in WCAG 2.0, addressing mobile accessibility, users with low vision, and users with cognitive disabilities. WCAG 2.0 Level AA is the current legal requirement under Ontario’s AODA. WCAG 2.1 Level AA is not yet legally required in Ontario, but organizations building or redesigning websites should target it now to be ready when the standard updates.
  • WCAG 2.0 Level AA has 38 success criteria in total — 25 at Level A and 13 additional criteria at Level AA. To be WCAG 2.0 Level AA compliant, your website must meet all 38 on each page being evaluated. There is no partial conformance.
  • No. Section 508 is a US federal law requiring federal agencies and federally funded organizations to make digital content accessible. It references WCAG 2.0 Level AA as its technical standard. AODA is Ontario’s provincial law. Both point to WCAG 2.0 Level AA, but they are different legal frameworks in different jurisdictions. If your organization operates in both Canada and the United States, you may have obligations under both.
  • Yes, frequently. WCAG compliance is about technical implementation and content quality, not visual design. A beautifully designed website can fail dozens of WCAG criteria. A visually striking site with low-contrast text fails 1.4.3. A modern UI with smooth animations but no keyboard support fails 2.1.1. A polished form with placeholder text but no persistent labels fails 3.3.2. Good design and WCAG compliance are compatible — but one does not guarantee the other.
  • Yes. WCAG 2.0 applies to web-based content including mobile-optimized websites. Native mobile applications downloaded from an app store are not explicitly covered by WCAG 2.0, though WCAG 2.1 addresses mobile web accessibility more thoroughly. Ontario’s AODA covers ‘internet websites and web content,’ which includes mobile-responsive websites.

Find out whether your website meets WCAG 2.0 Level AA

Understanding WCAG is the first step. Knowing whether your specific website meets it requires testing. Our WCAG compliance audit covers automated scanning, manual testing by a trained specialist, and screen reader evaluation — giving you a complete, prioritized picture of where your site stands.