AODA compliance means that since January 1, 2021, designated public sector organizations, and businesses or non-profits with 50 or more employees, must make public websites accessible. Content posted after January 1, 2012 must meet WCAG 2.0 Level AA, except live captions and pre-recorded audio descriptions. The organization that controls the site is responsible, even when an agency built it.
Your website is where people book appointments, find your phone number, read your policies and fill in intake forms. If someone using a screen reader, a keyboard or enlarged text cannot do those things, the site is failing them. For many Ontario organizations, it may also be failing a legal requirement.
The AODA rules for websites are short. The work behind them is not. Accessibility touches your colour palette, page templates, forms, PDFs, videos and the daily habits of everyone who edits the site. It also raises a practical question: who is responsible when an outside agency built the site?
This guide sticks to what the province states, translates WCAG 2.0 Level AA into plain checks, and sets out an audit sequence your team can run. It is written from the build side. We design and develop websites on Webflow, WordPress and Shopify from Saint John, New Brunswick, for organizations across Canada, including clinics and law firms where regulators already shape what a site can say. Here is what the law asks for, where sites tend to fall short, and how to fix the site itself rather than patch over it.
The AODA requires covered Ontario organizations to make their public websites accessible to people with disabilities. In technical terms, that means meeting WCAG 2.0 Level AA, minus two success criteria.
The Government of Ontario states that as of January 1, 2021, the Accessibility for Ontarians with Disabilities Act, 2005 requires all public websites to be accessible if you are a designated public sector organization or a business or non-profit organization with 50 or more employees. The requirement applies to websites and web content published after January 1, 2012. That content must meet the WCAG 2.0 Level AA success criteria, except 1.2.4 (live captions) and 1.2.5 (pre-recorded audio descriptions). The rules sit in the Information and Communications Standards of Ontario Regulation 191/11.
WCAG 2.0 is an internationally accepted standard developed by the World Wide Web Consortium (W3C). Each guideline has three levels of accessibility, A, AA and AAA, and each carries success criteria that describe exactly what must be achieved. In most cases you must meet the Level A criteria before you can meet Level AA, so treat Level A as the foundation, not a separate project.
Answer these for each website you run:
If every answer is yes, the requirement applies to that site and its in-scope content.
The organization that controls the website is responsible, whether that control is direct or through a contractual relationship. An agency that built the site, or a vendor that hosts it, does not take that duty off your hands.
Control has a specific meaning in the provincial guidance: direct or contractual control over the site's appearance, functionality and content. Content means any information found on a web page or web application, including text, images, forms and sounds. If your team can change what the site looks like, what it does or what it says, or can instruct someone who does, the obligation sits with you.
That has practical consequences for every AODA compliance website project. Your contract with any builder should name WCAG 2.0 Level AA as a requirement, say who tests against it, and say who fixes issues found after launch. We build sites for clinics and law firms, where regulators already shape what a site can say, and the same principle applies here: the organization answers for what it publishes, whoever wrote the code.
Internal websites, meaning an intranet or extranet, do not have to meet WCAG 2.0 Level A or AA. However, if an individual asks you to make content available in an alternate accessible format, such as large print or braille, you must work with that person to meet their needs.
Some content, such as complex maps or diagrams, may be impossible to make accessible. You can still post it. If someone asks for an accessible format you cannot provide, you must explain why the content is unconvertible and give them a summary of it. Section 14 of O. Reg. 191/11 covers these situations, so read it before you decide a piece of content belongs in this category.
WCAG 2.0 Level AA is a set of testable success criteria that decide whether people can perceive, operate and understand your site, including through assistive technology. In practice, much of the work comes down to a short list of checks your designers, developers and editors repeat on every page.
| Criterion | What it means | Common failure |
|---|---|---|
| Text alternatives for images | Every meaningful image has a text description; decorative images are hidden from screen readers | Team photos and banners with empty alt text or a file name as the description |
| Captions on pre-recorded video | Recorded video with speech has accurate, synchronized captions | Auto-generated captions that nobody reviewed, or no captions at all |
| Colour contrast | Text and key visuals stand out clearly against their background | Light grey body text, or white text on a pale brand colour |
| Resize text | People can enlarge text in the browser without losing content or function | Fixed-height boxes that clip or overlap text when zoomed |
| Keyboard access and no keyboard traps | Everything works with a keyboard alone, and focus can always move away | Pop-ups, chat windows or embedded maps that trap the Tab key |
| Visible focus | The element with keyboard focus has a visible indicator | Focus outline removed in the stylesheet for a cleaner look |
| Page titles and headings | Each page has a descriptive title, and headings describe the sections below them | Every page titled with the brand name; headings picked for font size |
| Link purpose | Link text, or its immediate context, says where the link goes | Rows of "Click here" and "Read more" |
| Language of page | The page declares its language in the code | Missing language attribute, so screen readers mispronounce the content |
| Form labels and error messages | Every field has a label, and errors are identified in text with a suggested fix | Placeholder-only fields; errors shown only as a red border |
| Consistent navigation | Navigation repeated across pages appears in the same order | Menus that reorder between templates or sections |
This table covers the criteria that trip up business websites, not the full standard. Use the official success criteria as your reference when you test, keep the two exclusions in mind, and remember that Level A comes first. Resize text and responsive layout overlap heavily, so if your site struggles on phones, start with our guide to make your website mobile friendly.
The same handful of patterns shows up again and again on business websites, and many start in design or content decisions, not in code. Each one has a clear fix.
If several of these show up on your site, the fix belongs in the templates and components. That is the core of accessible website design: solve the pattern once in the template so every page inherits the fix.
We recommend against relying on an accessibility overlay or widget to meet the AODA. A toolbar added on top of a site does not change the underlying code, so the barriers in your templates, forms and documents are still there.
This is our recommendation as builders, not a legal opinion on any product. An overlay adds a button that opens a panel of display options. None of that rewrites the page underneath. A form field with no label still has no label in the code. A menu that traps keyboard focus still traps it. A scanned PDF is still an image. People who use screen readers, magnifiers or switch devices bring their own assistive technology and settings, and that technology meets your original code, not the toolbar.
Our advice is simple: fix the site itself. Put the time and budget into correcting templates and components, training editors and testing with real assistive technology. If you are scoping that work, our breakdown of what a website costs in Canada helps frame the decision between remediation and a rebuild.
A sound website accessibility audit moves from automated checks to human testing, in that order. Each pass catches problems the one before it cannot, and a written log ties the whole effort together.
Accessibility is not a one-time project. New pages, plugins and uploads can reintroduce old problems, so the log and a scheduled recheck belong in your website care plan.
A redesign is the natural moment to build accessibility in, because every template and component is being rebuilt anyway. Put it into the design system, the content rules and the launch checklist, and every new page inherits it.
Set written rules for alt text, heading order, descriptive link text, captions and documents. We build on Webflow, WordPress and Shopify, and in all three an editor can undo a good template with one careless upload. Train editors on the alt text field, heading levels and how to publish an accessible document, then check their work.
Run the audit sequence above on every new template, feature or major batch of content before it goes live. Our guide on how to redesign a website covers where this fits in the wider project.
The W3C has published newer versions of WCAG, 2.1 and 2.2. Building to a newer version also meets 2.0 AA in most cases, but the AODA's stated requirement is WCAG 2.0 Level AA, so make sure your contract and test plan reference that standard explicitly.
Other provinces and the federal government have their own accessibility laws. If you operate outside Ontario, check which ones apply to you, and confirm their requirements directly instead of assuming the AODA rules carry over.
AODA compliance comes down to a few clear facts. Covered organizations must make their public websites meet WCAG 2.0 Level AA, minus two success criteria, and the organization that controls the site carries that duty even when an agency built it. A toolbar added on top does not change that. The lasting fix sits in the design system, the templates, the content rules and the habits of the people who publish. Audit in sequence, log what you find and fix, and build accessibility into your next redesign instead of patching it afterwards. If you want a team that designs and builds on Webflow, WordPress and Shopify to review your site and plan the work, book a free consultation with our team in Saint John.
