If you're looking into an AODA-compliant website in Toronto, you've probably been told that 31 December 2026 matters. It does, but often not for the reasons the sales emails give. Several ranking pages get the basics wrong. Some say every business must meet WCAG AA. Others name WCAG 2.1 or 2.2 as the legal standard. This guide explains what Ontario's rules ask of your website, what they don't, and what we would actually build to.
A note on accuracy: This is practical guidance from a web team, not legal advice. Confirm your obligations with the Government of Ontario's accessibility pages on ontario.ca, the Integrated Accessibility Standards Regulation (O. Reg. 191/11) or your legal counsel.
Short answer: does your Toronto business need an AODA-compliant website?
AODA duties apply to almost every Ontario organization with one or more employees. The specific website requirement is a separate rule. Section 14 of O. Reg. 191/11 requires designated public sector organizations and "large organizations" to make their websites and web content meet WCAG 2.0 Level AA. The regulation defines a large organization as one with 50 or more employees in Ontario.
The 2026 deadline is a different obligation. Businesses and non-profits with 20 or more Ontario employees must file an accessibility compliance report by 31 December 2026. After that, reports are due every three years (CFIB). The report covers all of your AODA obligations, not only your website.
Here is how that plays out. A 30-person firm has to file a report but has no legal WCAG website duty. A 60-person firm has both.
AODA website requirements by employee count
| Organization | Compliance report | Legal WCAG website requirement | Other duties |
|---|---|---|---|
| Private/non-profit, 1–19 Ontario employees | No | No | General AODA duties, such as customer service, training and accessible formats on request |
| Private/non-profit, 20–49 | Yes, by 31 Dec 2026 | No | General duties, plus the report |
| Private/non-profit, 50+ | Yes, by 31 Dec 2026 | Yes: WCAG 2.0 AA | Written policies and a multi-year accessibility plan |
| Public sector | Yes, every two years | Yes: WCAG 2.0 AA | Broader planning and reporting |
1–19 Ontario employees
You still have general AODA duties. One of them is providing information in accessible formats when someone asks. You don't file a report, and you have no legal WCAG requirement for your website.
Accessibility is still worth doing here. It makes forms easier to complete. Many accessibility practices, such as semantic headings and descriptive link text, also help search engines understand your pages. It also prepares you for growth, because rebuilding later, once you pass 50 staff, costs more.
20–49 Ontario employees
You must file the report by 31 December 2026, but the website rule doesn't apply to you yet. Read the report questions carefully and answer only what you can honestly certify. It is far easier to fix a gap now than after someone has signed the form.
50+ Ontario employees
You need to do three things:
- file the report
- meet the web content requirement
- keep accessibility policies and a multi-year plan
The website standard is WCAG 2.0 Level AA, with two exceptions named in the regulation: live captions (success criterion 1.2.4) and pre-recorded audio descriptions (1.2.5). It was phased in on two dates. From 1 January 2014, new sites had to meet Level A. From 1 January 2021, all sites had to meet Level AA. Both deadlines have passed, and the report is where you confirm you met them.
The scope has some nuance. The rule covers web content published after 1 January 2012. It applies to websites and web content, including web-based applications, that you control directly or through a contract that lets you modify them. There are limited exceptions where meeting the requirement isn't practicable. A third-party booking widget you can't change is treated differently from your own templates. You should still document why it falls outside your control, and look for an accessible alternative where one exists.
What is the AODA, and where do websites fit?
The Accessibility for Ontarians with Disabilities Act is Ontario's framework for removing barriers for people with disabilities. Website obligations sit in the information and communications section of the Integrated Accessibility Standards Regulation (IASR).
In practice, an accessible site works for people who:
- navigate with a keyboard instead of a mouse
- use screen readers
- rely on captions
- zoom in to 200% or more
- turn on high-contrast settings
- use other assistive technology
WCAG 2.0 AA, 2.1 or 2.2: which standard applies under AODA?
The legal standard named for AODA is WCAG 2.0 Level AA. It is not 2.1 or 2.2, whatever some agency pages claim.
WCAG 2.2 AA is still the better target for new builds. It covers problems that 2.0 predates, including:
- mobile interactions
- focus that disappears behind sticky headers
- tap targets that are too small
- login steps that rely on memory
| WCAG 2.0 AA | WCAG 2.2 AA | |
|---|---|---|
| Role | Legal minimum under AODA | Safer build target |
| When it makes sense | Fixing an existing site on a tight budget | New sites, rebuilds and apps |
| Cross-border value | Meets Ontario's rule | Closer to what US and international buyers expect |
Our default is to meet 2.0 AA for compliance and build toward 2.2 AA wherever the budget allows. Because 2.2 builds on 2.0, the extra work is usually small if you plan for it from the start.
Native mobile apps aren't named in the website rule. We still design them around the same patterns, such as adequate tap targets and visible focus, in our mobile app development work.
Core WCAG checklist for an AODA-compliant website
- Alt text that describes meaningful images. Leave the alt attribute empty on decorative images.
- Semantic headings in a logical order. Use the H1 consistently for the main page topic.
- Unique, descriptive page titles.
- Full keyboard navigation, with no keyboard traps.
- Visible focus states. Don't remove the outline without replacing it.
- Colour contrast of 4.5:1 for normal text and 3:1 for large text.
- Form labels and clear error messages that say what went wrong and how to fix it.
- Captions and transcripts for video and audio.
- Text resizing to 200% without breaking the layout.
- Skip links or logical navigation.
- Meaningful link text instead of "click here."
- ARIA used correctly, or not at all. Bad ARIA is worse than none.
- Accessible PDFs, or HTML alternatives.
- Screen reader compatibility across key journeys.
Toronto examples: common business websites
- Dental clinic booking form: Date pickers often fail keyboard users. Labelled fields and a plain-text fallback fix most of it.
- Law firm contact page: Watch for placeholder text used instead of labels, CAPTCHAs with no alternative, and error messages shown only in red.
- Ecommerce store selling across Ontario: Variant selectors, cart updates and checkout errors are where buyers drop off. They are also where audits find the most failures.
- Restaurant menu PDF: A scanned menu is just an image, so a screen reader can't read it. Publish the menu as an HTML page.
- Condo or property management portal: Logged-in dashboards, maintenance request forms and document libraries all count as web content.
- Multilingual service business: Set the correct language attribute on each page, or each section, so screen readers pronounce French, Punjabi or Tagalog content properly.
Why accessibility plugins and overlays aren't enough
Widgets can adjust font size or contrast for a visitor. They can't reliably fix:
- broken heading structure
- missing form labels
- illogical keyboard order
- inaccessible custom menus
- PDFs
- checkout errors
- unclear content
Those problems live in your code, design and content. A layer added on top doesn't change them.
Overlays also haven't protected businesses in the US. Litigation trackers keep reporting accessibility claims filed against sites that already had a widget installed. Many pages ranking for AODA terms are published by overlay vendors, so keep that in mind as you read them.
We fix accessibility at the source: the markup, how each component behaves, and the content.
How to test an AODA-compliant website properly
- Automated scans. Lighthouse and axe-style tools catch missing alt text, contrast failures and unlabelled fields. They find only part of the problem.
- Manual checks.
- Use the site with only a keyboard.
- Check contrast on real components.
- Submit every form with deliberate mistakes.
- Test at 200% zoom and on mobile.
- Assistive technology. Run your main journeys with a screen reader: the homepage, a service page, contact, and checkout if you have one. Then review your CMS content, because an editor can break accessibility with a single upload.
What proof to keep before filing the 2026 report
The report has to be certified by someone with authority to bind the organization, usually a senior officer (accessibility.works). A "yes" on the website question should have evidence behind it. Keep:
- a dated accessibility audit that states the standard tested against
- a remediation log showing each issue, its fix and the date
- before-and-after screenshots for major fixes
- automated scan results and manual test notes
- platform, theme and plugin notes, including any third-party content you can't modify
- a published accessibility statement with a feedback contact
- an inventory of PDFs and other content
- a recurring testing schedule (quarterly works for most sites)
AODA fines and enforcement
Section 37 of the AODA sets maximum fines for offences on conviction. A corporation can be fined up to $100,000 for each day an offence continues. An individual or unincorporated organization can be fined up to $50,000 a day. Directors and officers can also face personal liability.
These are prosecution ceilings. They are not the usual first outcome.
The Act also gives the province less severe tools. These include compliance orders and administrative monetary penalties, which the regulation sets separately and which are typically far smaller. In practice, enforcement has focused mostly on organizations that don't file their reports (accessibility.works).
Don't panic, but don't skip the report, and don't tick boxes you can't support.
How much does an AODA-compliant website cost in Toronto?
Budget for three separate costs and keep them as separate line items:
- the audit
- the remediation
- the ongoing monitoring
| Site type | Typical scope |
|---|---|
| Small brochure site | Targeted fixes to templates and content. Some small-site fixes may start in the hundreds. |
| WordPress/Webflow site | Template-level fixes plus content cleanup |
| Shopify/WooCommerce store | Theme, variant, cart and checkout work, plus product media. Usually a larger job. |
| Custom React/Next.js app | Component library, focus management and forms. Scoped per app. |
One Toronto agency, Move Forward Designs, cites $300–$1,200 for targeted fixes on small sites. Treat that as an illustration, not a market average. Most professional audits and remediation projects should be priced only after someone has reviewed the site.
The final price depends on:
- the number of templates
- content volume
- forms and checkout
- third-party embeds
- the size of your PDF library
Get the work scoped before you agree to a fixed number.
Platform notes: WordPress, Shopify, Webflow and Next.js
WordPress and WooCommerce
Theme quality decides most of the outcome. Page builders often produce messy markup and fake headings. Form plugins vary widely in how well they handle labels and errors. Common fixes include:
- WooCommerce checkout templates
- mobile menus
- heading order
- alt text on media
After the fixes, train your editors so the problems don't creep back.
Shopify
Start with a well-built theme, then check:
- alt text on every product image
- variant selectors (swatches are a common failure)
- focus behaviour in the cart drawer
- contrast on sale badges
Apps inject their own code, so audit them too. Then set content rules for whoever uploads products.
Webflow and Framer
Both give designers full visual freedom, which helps and hurts. Headings, landmark structure, focus states, reduced motion, contrast and form labels all need deliberate setup. This is where accessible web design and UI/UX design for accessible interfaces pay for themselves.
Next.js and React web apps
- Use accessible component patterns for modals, menus and tabs.
- With client-side routing, update the page title and move focus on each navigation.
- Give forms proper error states.
- Use ARIA only where native HTML can't do the job.
- Run automated accessibility tests in CI.
This is standard practice in our custom web application development.
AODA vs ADA: what cross-border businesses should know
AODA is Ontario legislation. The ADA is US civil rights law, and its risk comes mostly from lawsuits rather than regulatory reporting.
AODA obligations follow your Ontario employees and operations, not where your head office is (accessibility.works). A New York company with a Toronto team may be covered. A Toronto company selling into the US carries ADA risk.
Building one site to strong WCAG 2.2 AA practices is the simplest way to cover both. If you're weighing that decision across several markets, our consultancy and strategy team can help you plan it.
Accessibility also helps speed, SEO and conversions
Accessibility and SEO aren't the same thing, but they overlap. Many accessibility practices also help search engines understand your pages and help visitors find what they need, including:
- clean semantic HTML
- clear headings
- descriptive link text
- compressed media
Better form labels and error messages mean more completed enquiries.
Accessibility doesn't guarantee rankings. It does fit the standard we hold every build to: fast, secure websites that rank, convert and make the next step obvious. It works well alongside SEO and digital marketing.
A 30-day AODA website action plan
- Week 1:
- Confirm your Ontario employee count and which obligations apply.
- Inventory your pages, templates, forms, PDFs and third-party embeds.
- Run automated scans.
- Week 2:
- Run manual keyboard and screen reader tests.
- Rank issues by impact.
- Week 3:
- Fix the high-traffic templates first: header, navigation, forms and checkout.
- Update content, and replace or remediate PDFs.
- Week 4:
- Publish an accessibility statement.
- Build your evidence file.
- Schedule quarterly testing.
- If your organization has 20 or more Ontario employees, complete the full AODA compliance report, not just the website portion, and keep evidence for each answer.
With the deadline close, start now.
When to rebuild instead of patching
Sometimes remediation costs more than a rebuild. These are the signs:
- an old or abandoned theme
- a slow site with poor Core Web Vitals
- a page builder that produces inaccessible markup
- broken mobile UX
- a custom checkout with deep issues
- a heavy plugin stack
- no content governance
We'll tell you honestly whether WordPress, Shopify, Webflow or a custom Next.js build fits your budget and your team. Our recent website and application work shows the range.
Need help with an AODA-compliant website in Toronto?
Our Toronto team offers AODA website audit and remediation. That covers:
- a scoped audit
- a prioritized fix plan
- the fixes themselves
- the evidence file your senior officer needs before signing
If patching isn't worth it, we rebuild to WCAG 2.2 AA, with accessible web design from the first wireframe, so your new site is AODA-compliant from launch.
Book a free 30-minute scoping call and we'll tell you where you stand before 31 December.
