Does AODA apply to your website? A plain-English guide for Ontario businesses

If your organization has 20 or more employees in Ontario, you have an accessibility compliance report due on December 31, 2026. That’s about nine weeks away.

Most of what you’ll find online about AODA and websites is written by companies selling an accessibility widget, or by lawyers. Neither is written for the person who actually has to get the website fixed.

This is the developer’s version: which rules apply to you, what the standard actually asks of a website, what you can check yourself in fifteen minutes, and what to fix first. The legal side belongs to the official pages I link to throughout.

Which bucket are you in?

AODA (the Accessibility for Ontarians with Disabilities Act) applies to every organization with at least one employee in Ontario. What it asks of your website depends on your size and your sector.

Three details people miss.

• It covers content published after January 1, 2012. That’s almost everything on a typical business website.
• Two criteria are excluded. Live captions (1.2.4) and audio description for prerecorded video (1.2.5) aren’t required under AODA.
• You’re responsible even if an agency runs the site. The organization that controls the website, directly or through a contract, is the one that has to comply.

The province’s own page on how to make websites accessible under AODA is short and worth reading.

What WCAG 2.0 AA actually means, in plain English

WCAG stands for Web Content Accessibility Guidelines. The full WCAG 2.0 specification from the W3C is long, precise and not written for business owners. Underneath it are four ideas.

Perceivable: people can take in your content, however they access it

• Images have alt text that describes what they show, so a screen reader can read it out.
• Text has enough contrast against its background. Pale grey on white is the classic failure.
• Nothing relies on colour alone. A form field outlined in red, with no message, tells a colour-blind visitor nothing.

Operable: everything works without a mouse

• Every link, menu and button can be reached and used with a keyboard.
• You can always see where you are on the page, because the focused element is clearly outlined.
• Nothing traps you. A popup you can only close with a mouse is a dead end for a keyboard user.

Understandable: people can follow it and recover from mistakes

• Form fields have labels that stay visible while you type.
• Error messages say what went wrong and how to fix it, in words.
• The page declares its language, so screen readers pronounce it correctly.

Robust: assistive technology can make sense of the code

This one is mostly your developer’s job. Buttons are real buttons, not clickable boxes, and every control has a name a screen reader can announce.

Level AA is the middle of three levels. Level A is the floor, and AA adds requirements like a contrast ratio of at least 4.5:1 for normal text and pages that still work when zoomed to 200%.

Myths I keep hearing

“AODA requires WCAG 2.2”

It doesn’t. The regulation references WCAG 2.0 Level AA. WCAG 2.2 is the current W3C version and includes everything in 2.0, so if you build to 2.2 AA you’re covered and then some. It’s good practice, not the legal requirement.

“We’re small, so none of this applies”

Partly true. Under 50 employees, the WCAG website rule doesn’t apply to a private business or non-profit. But AODA covers every organization with at least one employee in Ontario, and duties like accessible customer service apply at every size. Separately, a website that shuts people with disabilities out can lead to a complaint under the Ontario Human Rights Code. The Ontario Human Rights Commission explains how that works. Your size changes your paperwork. It doesn’t change whether a customer can use your booking form.

“An accessibility plugin or overlay will make us compliant”

Overlays are the widgets that add a little accessibility icon to the corner of your site and promise compliance with one line of JavaScript. If it were that easy, this post would also be one line long.

An overlay can’t write meaningful alt text for your photos, can’t restructure a form that was built without labels, and often interferes with the screen readers people already use. The Overlay Fact Sheet is an open letter from accessibility practitioners explaining why, and it’s worth five minutes before anyone sells you one.

“Lighthouse says 100, so we’re fine”

Lighthouse, WAVE and similar tools are useful. I use them every week. But a tool can tell that an image has alt text, not that the alt text says “IMG_4471.jpg”. It can’t tell you whether your menu makes sense with a keyboard, or whether an error message helps anyone.

And those are only the errors a machine can find. Lighthouse is a smoke detector, not a building inspection.

A 15-minute self-check anyone can do

You don’t need a developer for this. Open your homepage and contact page on a laptop and work through the list. Write down anything that fails.

1. Put the mouse away (3 minutes). Press Tab to move forward, Shift+Tab to move back, Enter to follow a link or press a button. Can you reach every link and form field, always see which one you’re on, and close any popup?
2. Zoom to 200% (1 minute). Press Ctrl and + (Cmd and + on a Mac) until you hit 200%. Nothing should overlap or need sideways scrolling.
3. Run WAVE (3 minutes). Paste your homepage and contact page into WebAIM’s free WAVE checker. Red icons are errors. Start there.
4. Check image alt text (2 minutes). WAVE shows the alt text for each image. Ask: if the image disappeared, would the text tell me what I missed?
5. Test your form (2 minutes). Submit your contact form empty. Does it tell you, in words, which field is wrong and why? Do the labels stay visible while you type, or are they placeholder text that vanishes?
6. Check colour contrast (1 minute). WAVE’s Contrast tab flags low-contrast text. Light grey on white is the usual suspect.
7. Check your videos (1 minute). Do they have accurate captions?
8. Check your PDFs (2 minutes). Can you select the text in your menu or brochure? If it’s a scanned image, a screen reader can’t read any of it.

If you have ten more minutes, install NVDA, a free screen reader for Windows, and try to send yourself a message through your own contact form with your eyes closed. It’s the fastest way to understand what all of this is for.

What to fix first

You don’t need to fix everything at once. Fix in the order that affects real people most.

1. Forms and the flows that make you money. Contact, booking, quotes, checkout. If someone can’t finish the form, nothing else matters.
2. Navigation. A keyboard-usable menu, visible focus outlines and a “skip to content” link.
3. Colour contrast and text size. Usually a handful of colour values in the theme.
4. Images and link text. Meaningful alt text, and links that say where they go. “Read our pricing guide” instead of “click here”.
5. Content and documents. Headings, captions and PDFs. A PDF that’s just a page of text is often easier to turn into a web page.

Fix templates before pages. One fix to your header or form styles fixes every page that uses them.

If your site runs on WordPress

Theme, plugins and content are three different jobs

• The theme controls what appears on every page: the header and menu, focus styles, colours, the heading structure of your templates, and the skip link.
• Plugins add forms, sliders, booking widgets and cookie banners. Their accessibility varies a lot, and an update can change it.
• Content is what your team adds day to day: alt text, headings inside posts, link text and uploaded PDFs.

Page builders

Page builders can produce accessible pages, but you’re often working against the tool. Their tabs, accordions and sliders are where keyboard support most often breaks, so test those first.

Why fixes in the theme stay fixed

A fix made in the theme’s code applies to every page and survives content edits and plugin updates. A fix patched into individual pages, or layered on with a script, tends to quietly come undone. When I build a custom WordPress theme, labels, focus styles and heading structure are part of the templates, so nobody can delete them by accident.

Filing the compliance report (20+ employees)

I’m a developer, not a lawyer. Treat this as the practical walkthrough and the official page as the authority.

Before you start, have these ready:

• Your organization’s legal name
• Your business number (the BN9 on your tax return)
• Your number of employees
• Your certifier’s name and contact details. This is a senior officer with the authority to confirm the report is complete and accurate.

Then:

1. Open the Accessibility Compliance Reporting Portal and select “Sign In/Create Account” to register.
2. Sign in, select “New Submission” and choose “Accessibility Compliance Report”.
3. Answer the compliance questions and select “Submit”.
4. Keep the confirmation email. It goes to your certifier and primary contact and includes a confirmation number.

The province’s guide to completing your accessibility compliance report links to the portal and a step-by-step user guide. The form itself is shorter than most government forms, which is the warmest thing I have ever said about a government form.

If you’re 50 or more employees and not sure your website meets WCAG 2.0 AA, the next nine weeks are a good time to find out.

Bonus: accessibility helps SEO too

• Headings in order tell screen readers and search engines how the page is organized.
• Alt text is how search engines understand your images.
• Descriptive link text tells crawlers what the linked page is about.
• Clean, fast markup helps assistive technology and Core Web Vitals at the same time.

When I audited my own portfolio for SEO problems, the failures were things nobody noticed because nothing looked broken. Accessibility problems hide in exactly the same way. If you want both looked at together, that’s part of my technical SEO work.

FAQ

Does AODA apply if we’re based outside Ontario but serve Ontarians?

AODA is tied to having employees in Ontario, not to where your head office is. If you have at least one employee in Ontario, it applies, and your number of employees decides which rules. If you have none, that’s a question for a lawyer.

Do old pages from before 2012 count?

The WCAG requirement covers web content published after January 1, 2012. In practice, the menu, footer and forms around an older page almost certainly aren’t that old.

What are the penalties?

Under AODA, penalties can reach up to $100,000 per day for a corporation and up to $50,000 per day for an individual. Those are maximums. The sensible response is to file your report, find out where your site stands, and fix what’s broken.

Do PDFs count?

Yes. A PDF on your public website is web content. If the WCAG rule applies to you, your PDFs need to be accessible too, which usually means properly tagged PDFs or turning them into web pages.

How long does a fix usually take?

It depends on how the site is built. On a custom theme, template-level fixes like focus styles, contrast and menu behaviour are often a matter of days. Sites built with heavy page builders and lots of plugins take longer, because every widget has to be checked separately.

Want a second pair of eyes?

If you’d rather not do this alone, I offer a free 30-minute call. We’ll look at your site together, I’ll tell you what I’d fix first, and you’ll get a straight answer on how much work it is. There’s no widget to sell you.

Book a free 30-minute accessibility call →