WCAG 2.2 Accessibility Compliance Checklist for Canadian Business Websites

Running a business website in Canada means navigating a compliance landscape that just got stricter. The WCAG 2.2 accessibility compliance checklist for Canadian business websites is no longer optional reading — Ontario's AODA mandates WCAG 2.0 Level AA for most private-sector organizations, federal contractors face ACA obligations, and WCAG 2.2 is the current W3C standard courts and regulators are converging on. With 22% of Canadians living with a disability (Statistics Canada, 2017 Canadian Survey on Disability), inaccessible websites lock out roughly 8 million potential customers and expose your organization to significant legal risk.

Why Canadian Businesses Face Higher Accountability in 2026

Two regulatory frameworks define the stakes. The Accessibility for Ontarians with Disabilities Act (AODA) requires Ontario businesses with 20 or more employees to meet WCAG 2.0 Level AA — fines for corporations reach $100,000 per day. The Accessible Canada Act (ACA), enacted in 2019, applies to federally regulated industries and targets a barrier-free Canada by 2040.

Neither law explicitly cites WCAG 2.2 yet — but WCAG 2.2 is fully backwards-compatible with 2.0 and 2.1. Meeting 2.2 means exceeding current legal minimums while staying ahead of the regulatory curve. For Quebec businesses specifically, the Commission des droits de la personne has increasingly referenced WCAG as the benchmark in discrimination complaints related to digital access barriers.

The WCAG 2.2 Accessibility Compliance Checklist for Canadian Business Websites

This checklist is organized around the four WCAG principles. All items are Level AA unless noted — the target required under AODA and ACA for most Canadian organizations.

Perceivable

• Images carry meaningful alt text. Decorative images use alt='' — empty, not absent.
• Videos include synchronized captions and transcripts. Auto-generated captions do not qualify — accuracy must be verified manually.
• Color is never the sole conveyor of meaning. Errors, required fields, and links must use text labels or icons alongside color.
• Text contrast meets 4.5:1 for body copy, 3:1 for large text (18pt or 14pt bold). Verify every color combination in your palette with the WebAIM contrast checker.
• Content reflows at 400% zoom without horizontal scrolling (SC 1.4.10 Reflow).

Operable

• Every interactive element is keyboard-accessible. Tab through menus, modals, forms, and carousels without a mouse.
• Focus indicators are always visible. SC 2.4.11 Focus Not Obscured (new in 2.2): focused components must not be completely hidden behind sticky headers or overlapping layers.
• Touch targets meet the 24×24 CSS pixel minimum (SC 2.5.8, new in 2.2). Targets at 44×44px are ideal and align with Apple and Google Human Interface Guidelines.
• A skip navigation link is the first focusable element on every page.
• No keyboard traps. Modals and custom widgets must return focus to the triggering element when closed.
• Each page has a unique, descriptive title that reflects current content.

Understandable

• HTML lang attribute is declared. Use lang='en' or lang='fr' at the document level, and mark inline language changes for bilingual content.
• Error messages identify the problem and suggest a fix. «Required field» is not an error message. «Enter a valid 10-digit Canadian phone number» is.
• Navigation order is consistent across pages (SC 3.2.3).
• Help mechanisms appear in consistent locations (SC 3.2.6, new in 2.2). If a chat widget appears on your service pages, it must occupy the same position on every page where it is present.
• Multi-step forms do not require redundant data entry (SC 3.3.7, new in 2.2). If a user entered their email in step one, pre-populate it in step three.

Accessible Authentication

• Login flows do not rely solely on cognitive function tests (SC 3.3.8, new in 2.2). Standard CAPTCHAs requiring distorted text transcription fail this criterion. Use object recognition, email magic links, or passkeys instead.
• Password managers are never blocked. Preventing paste on password fields violates multiple criteria and creates barriers for every user, not just those with disabilities.

What Changed From WCAG 2.1 — Five Criteria That Affect Most Sites

WCAG 2.2 was published in October 2023. It removed one obsolete criterion — SC 4.1.1 Parsing, made redundant by modern browser standards — and added nine new success criteria. Five of the additions are Level AA and directly affect common patterns on Canadian business websites:

• SC 2.4.11 Focus Not Obscured (Minimum) — Sticky headers and floating chat bubbles frequently cover focused links. Fix with CSS scroll-margin-top or z-index adjustments on sticky elements.
• SC 2.5.8 Target Size (Minimum) — 24×24px floor for all interactive elements. Audit icon buttons, checkboxes, and pagination controls on mobile viewports first.
• SC 3.2.6 Consistent Help — Support links, phone numbers, and chat widgets must appear in consistent positions across every page where they are present.
• SC 3.3.7 Redundant Entry — Multi-step checkout flows and onboarding sequences are primary targets. Store and reuse previously submitted values within the same session.
• SC 3.3.8 Accessible Authentication (Minimum) — Replace CAPTCHA-only logins with at least one accessible alternative. Passkeys and email one-time passwords both satisfy this criterion.

How to Test: Tools and Process

Automated scanners catch roughly 30–40% of WCAG issues. Use them as a first pass, not a compliance certificate.

• axe DevTools (browser extension, free tier) — flags violations by criterion number directly in Chrome DevTools.
• WAVE (WebAIM) — visual overlay that shows errors, alerts, and structural landmarks across the full page.
• Lighthouse (built into Chrome DevTools) — an accessibility score of 90+ is a useful baseline but does not certify compliance.
• Manual keyboard test — disconnect the mouse. Navigate the entire site using Tab, Shift+Tab, Enter, Space, and arrow keys. Document every failure point.
• Screen reader test — NVDA on Windows (free) or VoiceOver on macOS and iOS (built-in). Focus on forms, modals, and content loaded dynamically by JavaScript.

Accessibility belongs in your pre-launch process alongside SEO and performance. The 50-point launch checklist for new websites covers both technical SEO and accessibility gates — run them in parallel, not in sequence.

Where to Start if Your Site Has Never Been Audited

Prioritize by impact and legal exposure. This order reflects the most common AODA violations cited in regulatory complaints:

1. Fix contrast failures across your color palette — the highest-frequency failure on Canadian business sites, and the most frequently cited in discrimination complaints.
2. Audit all images for alt text — a one-time effort that CMS editors can sustain with a simple style guide update.
3. Keyboard-test your five most-visited pages — homepage, primary service page, contact form, pricing page, and your main conversion flow.
4. Replace CAPTCHA with an accessible authentication alternative — now a WCAG 2.2 Level AA requirement, not an optional improvement.
5. Verify that client-side components render correct ARIA roles — JavaScript-rendered content is the most common source of screen reader failures in Next.js and React applications.

Accessibility and performance reinforce each other — semantic HTML loads faster and is easier for assistive technologies to parse. If Core Web Vitals are still on your backlog, the complete guide to website speed optimization addresses the same structural patterns that accessibility work improves.

At MedCode, WCAG compliance is built into every Next.js project from the component layer up — semantic headings, keyboard-accessible custom components, and accessible color systems are defaults, not post-launch patches.