Website accessibility in Ontario is both a customer experience issue and, for covered organizations, a legal requirement under the Accessibility for Ontarians with Disabilities Act (AODA). The most useful starting point is knowing whether the rule applies to your organization, what content is in scope, and how to prove that accessibility is maintained after launch.
According to the Government of Ontario’s website accessibility guidance, designated public-sector organizations and businesses or non-profits with 50 or more employees must make their public websites accessible. The organization that controls the website—directly or through a contractual relationship—remains responsible for the result.
What standard does Ontario require?
Ontario’s Information and Communications Standard requires covered public websites and web content published after January 1, 2012 to meet WCAG 2.0 Level AA, with exceptions for live captions and pre-recorded audio descriptions identified by the province. WCAG is organized around four principles: content should be perceivable, operable, understandable, and robust.
The legal baseline does not make newer guidance irrelevant. WCAG 2.2 is the current W3C Recommendation and adds practical criteria for focus visibility, dragging alternatives, target size, consistent help, redundant entry, and accessible authentication. Building to WCAG 2.2 Level AA can reduce risk in newer interfaces while preserving the WCAG 2.0 success criteria used by Ontario.
Which website content should you review?
Start with the public pages and functions your organization controls: marketing pages, ecommerce, appointment booking, account registration, customer portals exposed to the public, forms, downloadable documents, video, and third-party widgets selected by your team. Pay special attention to templates and shared components because one defect can repeat across hundreds of pages.
High-value user journeys deserve deeper manual testing. A homepage that passes an automated scan does not prove that a person can complete checkout, request an accommodation, submit an application, recover a password, or contact support using a keyboard or screen reader.
Common AODA website accessibility barriers
- Images that communicate information but have no useful text alternative.
- Form controls without persistent labels or clear error messages.
- Buttons and links without accessible names.
- Keyboard focus that is invisible, trapped, or placed in an illogical order.
- Text and interface controls with insufficient colour contrast.
- Headings and landmarks that do not describe page structure.
- PDFs that are untagged or difficult to navigate with assistive technology.
- Authentication steps that require memory, transcription, or inaccessible puzzles.
How to test an Ontario website
Use automated scanning for broad, repeatable coverage, then manually test keyboard operation, visible focus, zoom and reflow, screen-reader announcements, form errors, responsive layouts, and document accessibility. Include people with disabilities in usability testing whenever possible. Ontario’s guidance specifically recommends automatic assessment, assistive technology, user testing, feedback, and records of resolved issues.
Make accessibility part of publishing
The durable solution is a workflow. Give designers accessible component specifications, require developers to test semantic behaviour, train content authors on headings and alternative text, and add accessibility checks to release acceptance. Schedule recurring scans to detect drift after theme changes, plugins, campaigns, and new content.
Maintain a central issue register with severity, affected page, WCAG criterion, source snippet, owner, target date, and verification result. This converts an abstract compliance goal into measurable work and creates evidence for internal governance and future reporting.
This guide is general information, not legal advice. Consult the official Ontario requirements and qualified counsel for decisions about your organization.