WCAG 2.2 AA conformance is the practical accessibility standard for Canadian businesses in 2026. AODA (Ontario), ACA (federal), and provincial accessibility legislation mostly reference WCAG 2.0 or 2.1 AA, but the marketplace expectation is now 2.2 AA. Beyond legal compliance, accessibility improves usability for everyone and produces measurable conversion lift. **The substantive areas of WCAG 2.2 AA:** **Perceivable.** Users must be able to perceive the information presented. - All non-text content (images, icons, charts) needs text alternatives that convey equivalent meaning. Decorative images use empty alt attributes (`alt=""`). Functional images use alt attributes describing the function (`alt="Search"` on a magnifying glass icon button). - Colour contrast meets 4.5:1 for body text and 3:1 for large text (18pt+ or 14pt+ bold) and UI components. Test with WebAIM contrast checker or browser DevTools accessibility panel. - Information conveyed by colour alone (e.g., red error text without an error icon or label) must be available through other means. - Text can be resized up to 200% without loss of functionality or content. - Video content has captions; audio content has transcripts. **Operable.** Users must be able to operate the interface. - All functionality is available via keyboard. Test by unplugging the mouse and navigating the site entirely with Tab, Shift+Tab, Enter, Space, and arrow keys. - Focus state is always visible. Don't suppress browser default focus rings without providing equally visible custom focus styles. - No keyboard traps — users can always Tab away from every component. - Skip-to-main-content link at the start of the page allows screen reader and keyboard users to bypass repeated navigation. - Touch targets meet 24×24 CSS pixels minimum (WCAG 2.2 introduced this; the practical recommendation is 44×44 to meet platform conventions). **Understandable.** Information and operation must be understandable. - Page language is declared in HTML (`<html lang="en-CA">` or `<html lang="fr-CA">`). - Form fields have visible labels (placeholder text alone is insufficient). - Form errors are identified, described in text, and tied to the relevant field via ARIA or proximity. - Form submission shouldn't cause unexpected actions; users get clear confirmation of submission. - Navigation is consistent across pages. **Robust.** Content must be parseable by assistive technologies. - Use semantic HTML elements correctly (headings, lists, buttons, links). Don't fake buttons with styled divs. - ARIA attributes only where semantic HTML alone is insufficient. Misused ARIA is worse than no ARIA. - Custom components (modals, tabs, accordions, autocomplete) implement the appropriate ARIA pattern correctly. Reference the ARIA Authoring Practices Guide for patterns. **Audit and testing approach:** - Run axe DevTools or Lighthouse accessibility audit. Both catch many issues but neither is comprehensive. - Manually test keyboard navigation through critical user journeys. - Test with at least one screen reader (VoiceOver on Mac/iOS, NVDA on Windows, TalkBack on Android). Even casual screen reader testing catches many issues. - Test with browser zoom at 200%. - Test with reduced motion preference enabled. - Test colour contrast on all text and UI components. **Realistic expectations.** Most Canadian SMB sites have meaningful accessibility issues. Focused remediation typically achieves WCAG 2.2 AA within 4–12 weeks depending on site size and complexity. Sustaining accessibility requires ongoing discipline as new content and features are added — accessibility regressions accumulate quickly without monitoring or design system enforcement.