AODA Compliance: Accessibility Requirements for Websites

Direct answer: In Ontario, designated public sector organizations and businesses or non-profits with 50 or more employees must make public websites, web content, and web-based applications they control conform to WCAG 2.0 Level AA. The rule applies to content published after January 1, 2012. It has exceptions for live captions and pre-recorded audio descriptions. The January 1, 2021 deadline for covered organizations has passed; it is not a future grace period.

This guide explains who is covered, which pages and applications are in scope, how reporting thresholds differ, and how to build a practical conformance review. It is general information, not legal advice. Check the current regulation and Ontario guidance for your circumstances.

1. Who has to meet the AODA website requirements?

Organization	Website conformance duty
Designated public sector organization	Covered by the website rule, regardless of the business/non-profit employee threshold.
Business or non-profit with 50 or more employees	Must meet the public website requirements.
Business or non-profit with fewer than 50 employees	Ontario says the organization is not required under this IASR website rule to meet these website requirements, but encourages accessibility.

For businesses and non-profits, count employees against the 50-employee threshold for website conformance. Do not confuse it with the separate 20-employee threshold for accessibility compliance reporting. A reporting duty does not by itself change the website-conformance threshold.

The responsible party is the organization that controls the website. Control can be direct or arise through a contract that gives the organization the ability to modify the website or product. Using a vendor, hosted platform, or contractor does not automatically remove the organization’s responsibility. See Ontario’s website accessibility guidance.

2. What standard and level apply?

Covered websites and content must conform to the World Wide Web Consortium’s Web Content Accessibility Guidelines (WCAG) 2.0 Level AA. The regulation excludes two success criteria from this requirement:

1.2.4 Captions (Live)
1.2.5 Audio Descriptions (Pre-recorded)

Ontario notes that, in most cases, Level A criteria must be met before the required Level AA criteria can be met. Treat Level A as part of the practical work needed to reach Level AA, even though the stated target is Level AA.

This rule specifically names WCAG 2.0. Do not silently substitute a newer WCAG version when documenting the AODA rule. A team may choose to meet newer guidance as an additional product goal, but the legal requirement described here is WCAG 2.0 Level AA with the two stated media exceptions.

3. Which websites, pages, and content are covered?

The requirement applies to public websites and web content that the organization controls, including web-based applications. It covers content published after January 1, 2012. The regulation’s scope can include content and applications delivered by another party when the organization has contractual control that permits changes.

Make an inventory that includes more than the home page. Consider public landing pages, forms, account workflows, search, document libraries, embedded applications, and other web content published after the cutoff. Include pages that require authentication if they are part of a public-facing service or application; assess the actual scope and control rather than assuming that a login makes content exempt.

Are intranets and extranets covered?

Ontario guidance says internal intranets and extranets do not have to meet the public website WCAG 2.0 A/AA requirement. However, if someone requests information in an accessible alternate format, the organization must work with that person to meet their needs. See Ontario’s guidance on when public websites are not accessible.

Does old website content have to comply?

The website rule applies to web content published after January 1, 2012. The rule also applies to covered websites and web-based applications controlled by the organization. For older material, do not infer a blanket exemption for an entire site: identify when content was published, whether it has since been updated, and whether other accessibility duties or an accessible-format request apply. Check the regulation and Ontario guidance for the facts that apply.

What if meeting the requirements is not practicable?

The regulation provides a bounded, fact-specific exception where meeting the requirements is not practicable. Factors can include the availability of commercial software or tools and significant effects on implementation timelines planned or begun before January 1, 2012. This is not a general exemption for cost, inconvenience, or using a third-party platform. Document the relevant facts and confirm any exception against the regulation and the organization’s circumstances.

4. Website compliance and reporting have different thresholds

Duty	Who	Timing described by Ontario
Website conformance	Designated public sector organizations; businesses and non-profits with 50 or more employees	The historical deadline for the covered internet sites was January 1, 2021.
Accessibility compliance report	Businesses and non-profits with 20 or more employees	Every three years; the deadline stated by Ontario is December 31, 2026.
Accessibility compliance report	Designated public sector organizations	Every two years; the 2025 deadline was December 31, 2025. Ontario says late filers should submit as soon as possible.

These reporting dates and cycles are the Ontario guidance available for this article. Reporting is a separate obligation; filing a report does not establish that a website conforms, and the website threshold is not lowered to 20 employees because of reporting.

Read the relevant Ontario pages for business and non-profit rules and public sector rules before submitting a report.

5. A practical AODA website review workflow

Confirm coverage. Record the organization type, employee threshold, and the entity that controls the site. Review vendor and hosting contracts for rights to modify the service.
Inventory the experience. List public pages, web applications, forms, account flows, and content published after January 1, 2012. Note the owner, purpose, and critical user journeys for each area.
Map issues to WCAG 2.0. Assess Level A and Level AA criteria, noting the two excluded media criteria. Use the criteria to explain each issue and the user impact rather than recording only a scanner warning.
Combine automated and manual checks. Automated tools can find some code and content problems, but manual review is needed for issues that require human judgment and for testing real interaction flows. Ontario government-service guidance recommends manual and automated testing during beta; it does not say a scan certifies legal compliance. See Making government services accessible.
Test with assistive interaction methods. Review keyboard operation, focus order and visibility, headings and labels, form errors, zoom and reflow, and screen-reader output. Check captions and audio experiences against the applicable criteria and exceptions.
Fix and verify. Prioritize barriers that block core tasks, assign an owner and due date, make the correction, and retest the affected page and shared components.
Keep evidence and revisit. Maintain the inventory, findings, decisions, remediation notes, and follow-up results. Recheck when templates, content, vendors, or application workflows change.
Check reporting separately. Determine whether the organization must file an accessibility compliance report and track the applicable cycle and deadline.

What should an audit record contain?

Page, application, or user journey and the date reviewed.
WCAG 2.0 success criterion and a plain-language description of the barrier.
How the issue affects a user and whether it blocks a key task.
Test method, including automated scan, keyboard review, assistive technology, or manual inspection.
Assigned owner, planned correction, status, and retest result.
Any exception analysis, with the facts and rationale specific to the case.

6. Automated checks, manual review, and evidence

Automated checks are useful for repeatable detection of some issues, such as missing accessible names or certain structural problems. They cannot determine every question of meaning, clarity, task completion, or usability. A clean automated report is not proof that a site meets the regulation.

Manual review takes more time and requires accessibility knowledge, but it can evaluate real workflows and context. A balanced process uses automation to broaden repeatable checks and human review to assess interaction and user impact. Where appropriate, include people who use assistive technologies in product research and evaluation.

For screenshot-based visual review, a capture can help a team inspect rendered pages at selected viewport sizes, but it cannot establish keyboard or screen-reader conformance. For example, ScreenshotNeo is a website screenshot API and MCP server; use captures as visual review artifacts alongside accessibility testing, not as a compliance certificate.

7. Troubleshooting common AODA review problems

Problem	Likely cause	What to do
“We have fewer than 50 employees, so no accessibility work is needed.”	The website threshold is being confused with broader accessibility responsibilities or reporting.	Ontario says organizations below 50 employees are not required under this IASR website rule to meet these website requirements, but encourages accessibility. Check other applicable duties and accessible-format requests.
“We have 20 employees, so our site has to meet the 50-employee rule.”	The reporting threshold is being mixed up with website conformance.	Track reporting separately. The 20+ threshold applies to business/non-profit reporting; the website threshold is 50+.
“Our vendor owns the site, so we are not responsible.”	Technical hosting is mistaken for legal control.	Review the contract and determine whether your organization can require or make changes to the product. Responsibility can follow contractual control.
“The automated scan passed, so we are compliant.”	A tool result is being treated as complete conformance evidence.	Use manual review as well. Test keyboard use, forms, page meaning, and complete user journeys. Log what was and was not checked.
“Our intranet is exempt, so alternate formats do not matter.”	The public website exception is being read too broadly.	Ontario says intranets and extranets are outside this public-site WCAG requirement, while accessible alternate-format requests still need to be addressed.
“The deadline is 2021, so we can wait until then.”	A historical deadline is being read as a future date.	The deadline has passed. Covered organizations should assess current conformance and remediate issues; it is not a grace period.
“The content is old, so the whole site is exempt.”	The content publication cutoff is being applied to an entire site without checking scope.	Inventory publication and modification dates, distinguish individual content from the site and application, and review other duties and requests. Confirm interpretations against Ontario’s guidance.
“A practical difficulty automatically excuses the issue.”	The not-practicable provision is treated as a blanket waiver.	Assess the specific facts and factors in the regulation, record the rationale, and seek qualified legal guidance where needed.

8. Performance, reliability, and cost of the review

Accessibility review is ongoing work, not a one-time scan. Shared templates and components can make remediation more efficient because a fix can improve many pages, but each affected flow still needs verification. Prioritize by user impact and task importance, then schedule repeat checks when the site changes.

Automated scans are generally suitable for repeatable checks across inventories; manual evaluation consumes more reviewer time but covers important context that automation cannot judge. The research sources do not establish a universal audit duration, price, or tool accuracy, so estimate effort from the number of templates, content types, interactive flows, and assistive technology combinations in scope.

Keep reports and evidence tied to the exact site version and review date. That makes failures easier to reproduce and helps distinguish a fixed regression from an unreviewed change. Do not claim compliance based only on a scan, a screenshot, or a vendor statement.

9. Or skip the browser setup

If you need rendered screenshots to review how a page looks across states or viewports, you can call ScreenshotNeo directly. It does not replace WCAG testing, but it can provide visual artifacts without maintaining your own browser capture setup. The ScreenshotNeo API documentation describes the request options.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

Replace the example URL and API key with your target and key. ScreenshotNeo can return PNG, JPEG, WebP, or PDF. Its options include full-page and selector captures, viewport and device presets, retina scale, dark mode, custom CSS and JavaScript, wait conditions, request blocking, cookies and headers, caching, async jobs, bulk capture, and signed links. Cookie-banner cleanup, popup removal, and chat-widget removal can each be turned off. Responses identify page verdict and billing status in headers.

Cookie banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed. An MCP server lets AI agents use screenshot tools. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

10. Frequently asked questions

What WCAG level is required in Ontario?

WCAG 2.0 Level AA, with the regulation’s exceptions for live captions and pre-recorded audio descriptions.

Does AODA require every website in Ontario to comply?

No. The website rule identifies designated public sector organizations and businesses or non-profits with 50 or more employees, for sites and content they control. Other accessibility duties may still apply.

Does the AODA website rule cover a third-party web application?

It can. The relevant question includes whether the organization controls the application directly or through a contract that allows changes.

Can an accessibility scanner certify my website?

The Ontario guidance cited here supports using both manual and automated testing; it does not identify a single scan as certification. Treat scanner results as one source of findings.

When is the next business accessibility compliance report due?

Ontario’s current guidance states that businesses and non-profits with 20 or more employees file every three years, with a December 31, 2026 deadline. Verify the current instructions before filing.