What does an AODA compliant website need to meet?
An AODA compliant website meets WCAG 2.0 Level AA on its public pages and web content, with two exceptions: success criterion 1.2.4 on live captions and 1.2.5 on pre-recorded audio descriptions. That is Ontario's stated rule on its page about how to make websites accessible.
The Accessibility for Ontarians with Disabilities Act was passed in 2005, and the website rules sit in its information and communications standard, one of five standards alongside customer service, transportation, employment and design of public spaces. The website rule covers public sites and web content posted after 1 January 2012, and the compliance deadline for covered organizations was 1 January 2021.
WCAG 2.0 itself was published by the W3C on 11 December 2008 and is organised around four principles, often shortened to POUR: content must be perceivable, operable and understandable, and its code must be interpreted reliably by browsers and assistive technology. Level AA means meeting all Level A and Level AA success criteria. In daily terms that covers text alternatives for images, captions for pre-recorded video, logical headings, enough colour contrast, everything usable by keyboard, visible focus, no content that flashes dangerously, consistent navigation, labelled forms with clear errors, and code that assistive technology can interpret.
Who needs an AODA compliant website: does the 50-employee rule apply to me?
If you are a business or non-profit with 50 or more employees in Ontario, or a designated public sector organization, your public website must meet the standard. Smaller organizations have other AODA duties but no website rule on Ontario's summary of obligations.
Ontario's page on accessibility rules for businesses and non-profits splits obligations by size. With 1 to 19 employees, you must offer accessible ways for the public to give feedback. With 20 to 49, you also file an accessibility compliance report. With 50 or more, you document accessibility policies and tell the public they exist, create a multi-year accessibility plan and post it on your website, and make all public websites accessible.
Small organizations often choose an AODA compliant website anyway. Accessible sites work better for older customers and anyone on a phone in bright sunlight, they are easier for search engines to parse, and a business that grows past 50 staff will not have to rebuild. Designing accessibly from the start costs far less than retrofitting.
- 1–19 employees: accessible feedback methods; website rule not listed
- 20–49 employees: compliance report every three years
- 50+ employees: documented policies, multi-year plan posted online, accessible public websites
- Designated public sector: accessible websites and more frequent reporting
Which pages and content does AODA website compliance cover?
It covers your public website and web content posted after 1 January 2012; internal intranets and extranets are not required to meet WCAG under Ontario's guidance, except for the Government of Ontario and the Legislative Assembly.
“Web content” is broader than pages. It includes the documents you post, the videos you embed, the online forms, booking tools and stores your customers use. Ontario notes that the organization controlling the website, directly or by contract, is responsible, so a third-party booking widget embedded on your site is part of what your visitors experience.
During scoping we list everything public: page templates, forms, embedded tools, videos and downloadable files. Older content from before 2012 may fall outside the rule, but if it is still visited and still important, we usually recommend fixing it too, because the people using it do not know when it was posted. Your legal adviser can confirm the edges for your organization.
How is an AODA website audit done?
A proper audit combines automated scanning with manual testing by a person using a keyboard and screen readers. Automated tools find missing alt attributes, low contrast and empty links quickly; they cannot tell whether the alt text makes sense or whether a menu is usable.
We start by choosing a representative sample: every unique template (home, service, product, article, contact, checkout), every form, and the journeys that matter most, such as booking an appointment or placing an order. On each we run automated checks with tools such as axe and WAVE, then test by hand: tab through the page to check focus order and visibility, operate menus, tabs and modals with the keyboard, zoom to 200 per cent, turn off CSS, and listen with NVDA on Windows, VoiceOver on Mac and iPhone and TalkBack on Android.
Each issue goes into a log with the page, the WCAG 2.0 success criterion it fails, what a user experiences, a severity rating and the recommended fix. Because most issues come from shared templates and components, fixing one component often clears dozens of pages. The log becomes your evidence that the work was done and your to-do list for keeping the site compliant.
What we test by hand
Keyboard order and traps, visible focus, skip links, menu and modal behaviour, form labels and error announcements, heading outline, link purpose, reflow when zoomed, captions and transcripts, and reading order in screen readers.
What we do not do
We are developers, not a certification body. We do not issue certificates or legal opinions; we give you an honest log of what we tested, what failed and what we fixed.
Common reasons a website is not AODA compliant
Most Ontario sites that are not yet an AODA compliant website fail on the same handful of issues: poor contrast, images without useful alt text, forms without labels, menus and pop-ups that trap keyboard users, missing focus outlines and videos without captions. Almost all of them live in the theme or page builder, not in the words.
Contrast problems come from brand colours used for text: light grey on white, white on pale blue buttons. Heading problems come from choosing heading tags for their size rather than their meaning. Keyboard problems come from custom dropdowns, sliders and modals built with generic elements that do not respond to Tab, Enter and Escape. Form problems come from placeholder text used instead of labels and error messages shown only in red. Media problems come from embedded videos uploaded without captions.
Page builders deserve a special mention. Many generate deeply nested markup, duplicate headings and interactive widgets that screen readers struggle with, and fixing them page by page is slow. For sites built that way, a rebuild on a lean theme is often the cheaper route to an AODA compliant website, and we will price both options so you can choose.
Do accessibility overlay widgets make a website AODA compliant?
We do not rely on them, and we do not recommend them as a route to compliance. An overlay adds a script and a toolbar on top of your page; the underlying code, which assistive technology reads, stays the same.
Screen reader users already have their own tools configured the way they need. A toolbar offering bigger text or contrast modes duplicates browser features, and automatic fixes applied by script can guess wrong: auto-generated alt text that describes a photo inaccurately, headings reassigned incorrectly, or controls relabelled in confusing ways. Overlays also cannot fix PDFs, third-party embeds or complex forms, and they add another subscription and another script to load.
The honest route to an AODA compliant website is to change the code: correct HTML elements, proper labels, working focus management and captions. It is more work upfront and less work later, because accessible components stay accessible as you add pages. If you already pay for an overlay, we can audit the site with it switched off, since that is how many assistive technology users experience it, and plan the real fixes.
To turn an existing site into an AODA compliant website, we fix issues in order of impact: shared components first, because one fix repairs every page using them, then templates, then individual content. Each fix is checked against the original issue before it is marked done.
Typical component work includes rebuilding the main navigation so it opens and closes by keyboard and announces its state, adding a skip link, restoring visible focus styles, making modals trap focus correctly and return it on close, converting fake buttons to real buttons, and fixing carousels so they can be paused. Template work includes a single H1 per page, a logical heading outline, landmarks for header, navigation, main and footer, and correct language attributes. Content work includes alt text, link wording, table headers and captions.
We work in your code repository or theme through access you grant, on a staging copy first. You review changes on staging, then we deploy. Our redesign service is the better fit when the fix list is longer than the site is worth keeping.
Forms are where inaccessible sites lose customers and where an AODA compliant website most often falls short, so we test every one end to end with a keyboard and a screen reader. Every field needs a visible label tied to it in code, errors must be announced and explained in text, and focus should move to the first error.
Common fixes: replacing placeholder-only fields with real labels; grouping radio buttons with a legend; marking required fields in text, not only with an asterisk or colour; describing formatting rules (such as postal code format) before the user types; announcing errors with an alert region; keeping entered data after an error; and making sure a CAPTCHA has an accessible alternative.
Third-party tools are harder. Booking widgets, payment pages and chat tools come from vendors, and some are not accessible. We test them, document the problems, and suggest alternatives or configuration changes; where a vendor tool cannot be fixed, you have the evidence to take to the vendor. For stores, our ecommerce development page covers checkout builds that we control end to end.
On an AODA compliant website, documents and media count as web content, so PDFs need tags and reading order, and pre-recorded videos need captions. Live captions and audio descriptions for pre-recorded video are the two AA criteria Ontario excludes.
Many organisations have hundreds of PDFs, and fixing all of them is rarely the best use of budget. We inventory them and sort each into one of three buckets: convert to an HTML page (best for forms, policies and anything people read often), fix and tag the PDF (for documents that must stay as files), or archive and remove from public pages (for outdated material, with an offer to provide an accessible version on request).
For video, we check that captions exist, are accurate rather than raw auto-captions, and that the player itself can be operated by keyboard. Transcripts are a useful addition for podcasts and longer videos. Images of text, such as scanned menus or posters, need real text alternatives or an HTML version.
Building a new AODA compliant website from scratch
Building accessibly from the first design is the cheapest way to an AODA compliant website: colours are checked for contrast before approval, components are built with the right HTML elements, and testing happens as each template is coded rather than at the end.
We start with a small design system: text and background colour pairs that pass contrast, focus styles that are clearly visible, button and link styles that are distinguishable without colour alone, and type sizes that reflow when zoomed. Components such as navigation, accordions, tabs and modals follow established accessible patterns. Every template is keyboard and screen-reader tested before content goes in.
Content editors get guidance too: how to write alt text, how to use headings, how to name links. Accessibility erodes when new content goes in without that care, so the handover includes a short written guide and a recorded screen-share session. New accessible sites start at US$150 for up to 100 pages; larger sites and stores are priced on the table above.
WCAG 2.0, 2.1 or 2.2: which should an AODA compliant website target?
Ontario's rule names WCAG 2.0 Level AA, so that is the compliance target. Building to WCAG 2.1 or 2.2 AA is a sensible extra, and the W3C states that content conforming to WCAG 2.2 also conforms to 2.1 and 2.0.
WCAG 2.1 was published in June 2018 and WCAG 2.2 in October 2023. The later versions add criteria that matter especially on phones and for people with low vision or cognitive disabilities, such as content that reflows without horizontal scrolling, larger target sizes, and focus that is not hidden by sticky headers.
Our default is to build new sites so that they meet the newer criteria where it costs little, and to report audits against WCAG 2.0 AA as the Ontario baseline, noting any 2.1 or 2.2 issues separately. That way you know what the regulation asks for and what would make the site better, and can budget for each.
AODA compliance reports and the December 2026 deadline
Ontario businesses and non-profits with 20 or more employees must file an accessibility compliance report every three years, and Ontario lists the next deadline for them as 31 December 2026. Reports are filed through the Accessibility Compliance Reporting Portal.
The report covers your organisation's AODA obligations broadly, not only the website, and Ontario's compliance reporting page warns that not completing it can lead to enforcement measures including financial penalties. Filing is your organisation's task; we do not file on your behalf.
Where we help is in making the website part of the report something you can answer with confidence. Our audit log shows which pages and templates were tested, against which criteria, what failed and what was fixed, with dates. If the report deadline is close, tell us in the first message and we will scope the audit to your highest-traffic templates and journeys first.
Does an AODA compliant website rank better?
Accessibility is not a direct ranking promise, but many accessibility fixes overlap with good SEO: clear headings, descriptive link text, alt text, fast lean pages and proper HTML all help search engines and AI assistants understand your content.
The overlap is practical. A logical heading outline gives Google a clear structure. Captions and transcripts turn video into indexable text. Descriptive link text helps both screen reader users and crawlers understand where links go. Lean themes that pass accessibility tests also tend to load faster, which helps Core Web Vitals. None of it guarantees rankings, and nobody can honestly guarantee them, but you are not trading search visibility for accessibility.
If you want search work alongside accessibility, our technical SEO service for Canadian sites starts at US$150/mo a month, and we coordinate so changes for one do not undo the other.
AODA compliant website checklist you can run in 20 minutes
This quick check will not replace an audit, but it shows whether your site has obvious problems. Use your homepage, one inner page and your main form.
- Unplug the mouse and press Tab: can you reach and see every link, button and field?
- Open the menu and any pop-up with the keyboard; can you close it with Escape?
- Zoom the browser to 200 per cent: does text reflow without cutting off?
- Check light grey or coloured text against its background with a contrast checker
- Submit your form with errors: are they explained in words, not only colour?
- Turn on VoiceOver or NVDA: do images and buttons announce something meaningful?
- Play a video: are there accurate captions?
- Open a PDF: can you select text, and does it have headings?
- If you have 50+ employees, is your multi-year accessibility plan posted on the site?
If more than two of these fail, a full audit is worth it. Send us your site address and we will quote one within about two working days.
Working with a team in India on AODA website compliance
For AODA compliant website projects, our evenings in India overlap Ontario mornings, so calls happen early in your day and work continues while you sleep. Findings and fixes are shared on a staging site and a shared issue log you can open any time.
The first two weeks usually look like this. Days one and two: a video call to agree scope, then access to your site and a list of templates and journeys to test. Within about two working days you get an itemised quote. Once approved, days three to eight are the audit; you receive the issue log and a short summary call. Remediation starts straight after, on staging, with progress updates on WhatsApp or email.
You keep ownership of the domain, hosting, code and accounts, and you can remove our access at any time. We invoice from India in USD, payable in USD or CAD by Wise, wire or PayPal; tax treatment is for your accountant. We do not visit offices or run in-person user testing sessions. If you need testing with disabled participants, we can work alongside a local testing partner you choose. Our page on working with an offshore web team explains the model in more depth.
Example: a Hamilton home-care provider fixing its site
This is a hypothetical scenario to illustrate the process. Say a Hamilton home-care provider with 80 staff has a WordPress site on a page-builder theme, a job application form, a service enquiry form and 60 PDFs, and needs confidence in its website before filing its compliance report.
The audit would cover 8 templates, both forms and the PDF inventory. Likely findings: a mega-menu that cannot be closed by keyboard, low-contrast grey body text, form fields labelled only with placeholders, a slider that auto-plays with no pause button, headings used for styling, and untagged PDFs. The issue log maps each to its WCAG criterion.
Remediation would rebuild the menu and slider components, adjust the colour palette with the provider's approval, relabel both forms with proper error handling, fix the heading outline in the templates, and split the PDFs: care policies converted to HTML pages, forms rebuilt online, old newsletters archived. After retesting, the provider has a site that works with screen readers and keyboards, an issue log with dates and a short editing guide for staff. Its multi-year accessibility plan is posted on a new accessibility page.