AODA Website Requirements in Ontario for 2026: A Business Guide

A practical 2026 guide to Ontario AODA website rules, employee thresholds, WCAG scope, testing, remediation, and accessibility project evidence.

For an Ontario business or non-profit with 50 or more employees, public websites it controls generally need to meet WCAG 2.0 Level AA under the AODA, with two stated exceptions. A separate rule requires businesses and non-profits with 20 or more employees to file an accessibility compliance report by December 31, 2026. The 20-employee and 50-employee thresholds answer different questions.

This guide is practical project-planning information, not legal advice or a compliance certification. Confirm which rules apply to your organization with the Government of Ontario's current guidance and, where the answer affects a legal declaration, qualified counsel.

The short answer by organization size

Ontario organization	2026 reporting	Public-website rule
No employees in Ontario	The Ontario business guidance says the organization is exempt from these AODA business rules.	The 50-employee website threshold is not reached.
1–19 employees	No three-year compliance report based on headcount.	The specific 50-employee public-website requirement is not triggered by size alone, but other accessibility duties still apply.
20–49 employees	File the business or non-profit report by December 31, 2026.	Reporting does not by itself create the 50-employee website requirement. Other information, customer-service, training, and employment duties still apply.
50 or more employees	File the report by December 31, 2026.	Controlled public websites and applicable web content must meet the AODA web standard.
Designated public sector	A separate two-year reporting schedule applies.	Designated public sector organizations are included in the public-website requirement.

Ontario's employee-count instructions include full-time, part-time, seasonal, and certain contract workers, but exclude employees outside Ontario, volunteers, and independent contractors. Because the distinction between a contract worker and an independent contractor depends on the working relationship, use the province's instructions rather than a website headcount guess.

What the December 31, 2026 deadline actually means

The deadline is for the accessibility compliance report required from Ontario businesses and non-profits with 20 or more employees. The report confirms that the organization has met the accessibility requirements that currently apply to it. It is not a new date on which every business website suddenly becomes subject to WCAG.

The official reporting page says a senior officer with legal authority certifies the report. That makes the useful project question broader than “did a scanner produce a good score?” The organization needs a defensible view of its applicable requirements, the website scope it assessed, the barriers it found, the fixes it verified, and any unresolved items requiring legal or operational review.

Which websites and content are in scope?

Section 14 of Ontario Regulation 191/11 applies the website requirements to internet websites, web content, and web-based applications that an organization controls directly or through a contractual relationship that allows the product to be modified. It also limits the web-content requirement to content published after January 1, 2012 and includes a practicability qualification.

For project discovery, inventory more than marketing pages:

public forms, booking flows, account registration, and payment steps;
downloadable PDFs, menus, instructions, policies, and reports;
videos, audio, images, charts, maps, and other non-text content;
customer-facing portals or web applications;
third-party widgets that the organization can configure or replace;
new content that staff publish through the CMS after launch.

The province provides separate guidance for internal intranets, older content, live captions, pre-recorded audio descriptions, and content that cannot practicably be converted. Do not turn a brief article into a legal conclusion about those exceptions.

Is the standard WCAG 2.0 or WCAG 2.2?

The Ontario regulation names WCAG 2.0 Level AA. It excludes success criterion 1.2.4 for live captions and 1.2.5 for pre-recorded audio descriptions from the large-organization website schedule. That is the provincial legal baseline described by Ontario.

W3C also publishes WCAG 2.1 and WCAG 2.2. Its WCAG overview explains that later versions add criteria without replacing the earlier standards, encourages use of the latest version, and states that content conforming to WCAG 2.2 also conforms to 2.1 and 2.0. A website project can therefore choose WCAG 2.2 AA as its technical target while documenting the AODA 2.0 AA requirements separately. Put the exact target in the scope; do not let “accessible” remain an undefined adjective.

An automated accessibility score is not proof

Automated testing is useful for repeatable checks such as missing programmatic labels, some contrast failures, invalid relationships, and certain document-structure problems. It cannot determine whether alternative text communicates the purpose of an image, whether focus order matches the task, whether an error message is genuinely understandable, or whether a complex interaction works well with assistive technology.

The W3C guidance on evaluation tools says tools cannot automatically check every accessibility aspect and require human judgment. Ontario similarly recommends automated and manual assessment, assistive-technology testing, user feedback where possible, and a record of resolved issues. A credible plan combines these methods and states what was not tested.

Use the four-owner remediation map

In AP Works website discovery and QA, page count is rarely the most useful way to assign accessibility work. We separate barriers by the owner who can actually prevent them from returning: shared interface, content, third party, and operating workflow.

1. Shared interface

Navigation, forms, modals, carousels, accordions, buttons, focus styles, error patterns, and headings often repeat across the site. Repairing the component once—and testing every state—usually creates more durable value than fixing the same symptom page by page.

2. Content

Alt text, link purpose, heading order, captions, document structure, plain instructions, and meaningful error copy depend on editorial decisions. A developer can create the fields and validation, but the organization still needs an owner and guidance for future publishing.

3. Third party

Booking, chat, maps, payment, consent, video, and embedded forms can introduce barriers outside the main codebase. Record whether each tool can be configured, upgraded, contractually modified, replaced, or accompanied by an accessible alternative. “The vendor owns it” does not make the user journey disappear.

4. Operating workflow

A site can pass at launch and regress the next week. CMS permissions, editorial training, document templates, release checks, and a feedback path determine whether accessibility survives routine updates. The project handoff should name who reviews new pages, PDFs, media, and integrations.

What evidence should a website project produce?

AP Works uses an evidence-first delivery pattern so a decision-maker can see what was included, how it was tested, and what remains. For an accessibility-focused website project, request an evidence pack containing:

Applicability note: the organization type, employee band, sites, and legal requirements supplied or confirmed by the client and its adviser.
Scope inventory: representative templates, critical tasks, documents, media, and third-party services.
Declared target: the exact WCAG version and level used for design, development, and acceptance.
Test matrix: automated checks, keyboard paths, zoom and reflow checks where applicable, assistive-technology coverage, browsers, devices, and manual criteria.
Issue register: the barrier, affected users or task, responsible owner, priority, fix, retest result, and supporting evidence.
Known limits: untested areas, third-party constraints, exceptions under review, and items needing legal confirmation.
Maintenance plan: CMS guidance, staff ownership, feedback handling, regression checks, and a review cadence.

This is not a certificate. It is a transparent project record that helps the organization make its own report accurately and maintain the work after launch.

Should you remediate, rebuild components, or replace the website?

Condition	Usually the smallest useful response
The structure is sound and barriers are isolated	Remediate the affected code and content, then retest critical tasks.
Failures repeat across navigation, forms, or templates	Rebuild the shared components or design system before fixing individual pages.
The CMS cannot preserve semantics or accessible authoring	Change the authoring model, theme, or platform; train the people who publish.
Critical third-party flows cannot be configured or replaced	Escalate the product and contract decision, and design an accessible alternative where appropriate.
The site is also undergoing a major content, platform, or ownership change	Plan accessibility into the rebuild, with acceptance criteria before design approval.

A redesign is not automatically an accessibility fix. It can recreate the same barriers in a more polished interface. If platform ownership is also part of the decision, compare the maintenance and handoff questions in our custom code versus WordPress guide.

Questions to ask a website partner

Which WCAG version and conformance level will be written into the scope?
Which pages, templates, tasks, documents, media, and integrations will be tested?
Which checks are automated, manual, keyboard-based, and assistive-technology based?
Who decides whether a failure is fixed, accepted, or escalated?
How will findings and retest evidence be delivered?
How will inaccessible third-party tools be handled?
What prevents authors from reintroducing barriers after launch?
Which claims require legal review rather than a developer's opinion?

When we scope a custom website, accessibility can be defined as a concrete design, development, testing, and handoff requirement. Specialized compliance analysis, legal interpretation, and certification are separate responsibilities and should be identified explicitly.

Sources and further reading

Scope accessibility into your website project →