AODA Website Compliance: My Checklist for Ontario Businesses

If I’m reviewing an Ontario business website, I don’t treat accessibility as a plugin, a badge, or a one-time legal checkbox. I look at whether a customer can understand the page, move through it without a mouse, complete the main task, and get help when the website or physical location creates a barrier for them.

The short answer: Under Ontario’s Accessibility for Ontarians with Disabilities Act (AODA), the website rule requires designated public-sector organizations and businesses or non-profits with 50 or more employees in Ontario to make covered public websites and web content conform to WCAG 2.0 Level AA, with limited exceptions. Smaller businesses still have accessibility duties, including accessible customer service and providing accessible information or communication supports on request.

I’ve spent more than 15 years in marketing, including agency-side SEO, GEO and paid advertising for local businesses. My role here isn’t to replace legal advice or a formal accessibility audit. It’s to help an Ontario business owner understand the threshold, ask better questions and fix the digital barriers most likely to stop a customer.

Why I chose AODA website compliance

A recent r/Hamilton discussion about finding a genuinely accessible local facility drew a practical set of questions. Could a wheelchair user enter? Was there a roll-in shower? Could a support person help? Would the space be private and safe? The thread wasn’t legal guidance, but it captured a real customer problem: vague accessibility claims force people to investigate basic facts before they can decide whether to visit.

I use Reddit to identify questions and customer language, not as the authority. I checked the legal points in this guide against current Ontario government guidance, Ontario Regulation 191/11 and the World Wide Web Consortium’s accessibility resources on August 17, 2026.

What does the AODA require from an Ontario business website in 2026?

The first question is organization size. Ontario’s current website accessibility guidance says the WCAG requirement applies to designated public-sector organizations and businesses or non-profits with 50 or more employees in Ontario. Covered public internet websites must conform, and the web-content requirement applies to content published after January 1, 2012. The standard is WCAG 2.0 Level AA, except success criteria 1.2.4 for live captions and 1.2.5 for prerecorded audio descriptions.

Ontario’s current compliance-report page confirms the December 31, 2026 deadline for businesses and non-profits with 20 or more employees in Ontario. The report is required every three years. Businesses and non-profits below 20 employees in Ontario do not file, but that does not erase the accessibility requirements that otherwise apply to them.

Ontario’s business and non-profit accessibility rules explain how to count employees. The count includes full-time, part-time and seasonal employees, plus contract workers, while excluding employees outside Ontario, volunteers and independent contractors.

The legal text matters when scope is unclear. Section 14 of Ontario Regulation 191/11 addresses websites, web content and web-based applications an organization controls directly or through a contractual relationship that allows the product to be modified. It also contains a practicability qualification. If an old platform, vendor contract or unusual content creates a hard case, I would document the facts and get qualified legal or accessibility advice rather than assume the work is exempt.

Why I would not stop at the 50-employee threshold

Ontario’s accessible customer service standard applies to businesses and non-profits with one or more employees in Ontario. Ontario also says organizations must let people know that written information and other communications can be provided in an accessible format or with communication supports on request. The organization must work with the person, provide the material in a timely way and not charge more than it normally would.

The Ontario Human Rights Commission also explains that service providers have a duty to accommodate disability-related needs to the point of undue hardship. AODA thresholds do not define the whole human-rights analysis. That is one reason I would not tell a small business that accessibility is optional simply because it has 12 employees.

My practical AODA website compliance checklist

1. Can customers finish the important journeys?

I’d start with tasks, not a score. Can someone find the location, understand the service, call the business, book an appointment, complete a form, buy a product or request an accessible format? For a multi-location business, each location page should state the facts for that location instead of hiding them behind a generic accessibility claim.

Write down the three to five tasks that matter most. Test each one with a keyboard, at high zoom and with a screen reader. Include mobile. A homepage can look polished while the booking widget, payment screen or form confirmation remains unusable.

2. Does the page have meaningful structure?

Check that every page has a descriptive title, one clear main heading, logical subheadings and real lists where the content is a list. Link text should explain the destination without relying on “click here.” The page language should be set correctly, and buttons should have names that describe their action.

This is the foundation that lets assistive technology interpret the page. It also makes content easier to scan and maintain. Visual size alone does not turn a line of text into a heading, and a clickable image does not become understandable until its purpose has an accessible name.

3. Can I operate everything with a keyboard?

Use Tab and Shift+Tab to move through the header, menus, pop-ups, forms and footer. Focus should move in a sensible order and remain visible. Check that a keyboard user can open and close menus, dismiss a modal, choose a date, submit a form and escape anything that traps focus.

A “skip to content” link can save repeated navigation. Custom controls are a common source of trouble, especially when a design replaces native buttons, links or form fields with scripts that only respond to a mouse click.

4. Is the text readable without relying on colour?

WCAG 2.0 Level AA calls for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, with defined exceptions. Test text over solid colours, gradients, photos, button states and error messages. Check that colour is not the only way the site identifies a required field, sale price, active tab or error.

Then zoom the page to 200%. Text should remain readable and controls should not disappear or overlap. Avoid locking text into images when ordinary HTML text can do the job.

5. Do images and media have useful alternatives?

Meaningful images need alternative text that communicates their purpose in context. Decorative images should usually have empty alt text so a screen reader can skip them. I do not stuff keywords into alt text or begin every description with “image of.” A logo, chart, map and staff photo each need a different treatment because they do different jobs.

Prerecorded video with meaningful audio should have accurate captions. Audio-only information needs a text alternative. If a visual demonstration carries information that the audio never explains, add a description in the narration or nearby content. The AODA exclusions for live captions and prerecorded audio descriptions are narrow legal exceptions, not a reason to leave the rest of the media inaccessible.

6. Are forms forgiving and clearly labelled?

Every input should have a persistent label that is programmatically connected to it. Placeholder text is not a reliable substitute. Instructions should appear before they are needed, required fields should be identified in more than one way, and error messages should say what went wrong and how to fix it.

Test forms without a mouse and without perfect input. What happens when a phone number is formatted differently, a required field is missed or a session times out? The W3C’s form-label guidance explains why properly associated labels help screen-reader users and also create a larger clickable area for everyone.

7. Have I checked PDFs, menus and third-party tools?

A website audit that ignores downloadable files is incomplete. Menus, price lists, intake packages and reports may be scanned images with no usable text or structure. Where possible, I publish important information as accessible HTML and treat a PDF as an optional format, not the only path.

Also inventory the booking system, chat, maps, cookie controls, payment tools, review widgets and embedded forms. A vendor name or accessibility badge is not evidence that the customer journey works. Ask vendors for current conformance information, test each component and document any limitation or fallback.

8. Does the website publish concrete accessibility information?

“Wheelchair accessible” can be too vague to support a decision. When relevant, I would publish current facts about parking, curb cuts, entrance width or steps, automatic doors, elevators, seating, washrooms, change rooms, service animals, support persons and quiet or low-sensory options. Include a direct way to ask a question before visiting.

Only state what the business has verified. Use current photos when they help, but describe the key facts in text. If an elevator, ramp or accessible washroom is temporarily unavailable, Ontario’s customer-service guidance says organizations should give notice of the disruption, including the reason, expected duration and available alternatives.

9. Can someone request help in more than one way?

I would give customers a phone number and an accessible digital contact option, then explain how to request an accessible format or communication support. The feedback route itself needs to be accessible. If the only option is a form that someone cannot operate, the fallback has failed.

Ontario’s accessible-information guidance recommends consulting with the person about the format or support that works for them. That is better than assuming every customer with a similar disability needs the same solution.

10. Is accessibility part of the publishing process?

Accessibility can regress when a new promotion launches, a plugin changes, a video is uploaded without captions or a staff member pastes badly structured content. Add a short accessibility checklist to the same workflow used for content, design and technical QA.

Someone should own the process. Editors need to know how to write headings, links and alt text. Designers need contrast and focus requirements. Developers need keyboard and assistive-technology testing in acceptance criteria. Procurement needs accessibility questions for third-party tools. A practical process is more durable than a cleanup sprint every few years.

How I would audit an Ontario local-business website

1. Confirm scope. Record the organization type, employee range, public websites, web apps, content dates, contracts and the December 31, 2026 reporting deadline if it applies.
2. Inventory templates and tasks. Include service pages, location pages, blog posts, forms, checkout, booking, account areas, PDFs and third-party embeds.
3. Run automated checks. Use them to find detectable issues such as missing names, contrast failures, duplicate IDs and structural errors. Treat the results as leads, not a certificate.
4. Test manually. Navigate by keyboard, zoom, inspect headings and labels, and use a screen reader on representative tasks.
5. Prioritize blocked outcomes. Fix anything that prevents contact, booking, purchase, login or access to essential information before cosmetic warnings.
6. Retest and document. Record the page, issue, WCAG criterion, owner, fix and verification date. Keep known limitations and alternate routes visible.
7. Include people with disabilities. W3C recommends combining standards-based evaluation with user involvement because each reveals issues the other may miss.

An automated score is useful for triage, but it cannot decide whether alt text communicates the right idea, whether instructions make sense or whether a booking journey is practical. Ontario’s own website guidance recommends automated assessment, assistive-technology testing and feedback from people with disabilities. I would use all three in proportion to the risk and complexity of the site.

Four mistakes I would avoid

Calling an overlay or toolbar a complete solution

A toolbar may provide useful display preferences, but it does not automatically repair the underlying headings, labels, keyboard behaviour, documents or third-party code. I would evaluate the actual experience and the relevant success criteria instead of treating the presence of a widget as proof.

Fixing only the homepage

The most valuable page may be a service page, booking form or checkout. Scope the whole public journey and sample every template. Content added after the initial project needs the same controls.

Publishing an unverified compliance claim

I would not write “fully AODA compliant” because an automated tool returned a high score. State the standard, scope, testing methods, date and known limitations. If a formal claim is necessary, get an appropriate conformance review and legal guidance.

Treating accessibility and SEO as the same audit

There is useful overlap. Clear headings, descriptive links, text alternatives and crawlable text can help both people and search systems understand a page. But an SEO audit does not prove WCAG conformance, and accessibility is not a ranking guarantee. I keep the objectives distinct while coordinating the work.

Frequently asked questions

Does an Ontario business with fewer than 50 employees need an accessible website?

The specific AODA rule requiring private and non-profit organizations to make covered public websites meet WCAG 2.0 Level AA applies at 50 or more employees in Ontario. Smaller organizations still have AODA customer-service and accessible-information duties when they have one or more employees in Ontario, and the Ontario Human Rights Code can require disability-related accommodation. Get legal advice for your facts rather than treating the threshold as blanket permission to leave barriers in place.

Does the AODA require WCAG 2.1 or WCAG 2.2?

Ontario Regulation 191/11 currently names WCAG 2.0 Level AA for the covered private-sector and non-profit websites, with the two stated exceptions. W3C has since published WCAG 2.1 and 2.2. For new website design work, I would consider WCAG 2.2 Level AA as a stronger practical target where feasible, while documenting the standard used. That is a design recommendation, not a claim that Ontario’s regulation has changed to 2.2.

Can a free accessibility checker prove compliance?

No. It can identify some machine-testable failures and help monitor regressions. It cannot determine every success criterion or replace keyboard, screen-reader and task-based testing. Use automated tools as one part of a documented evaluation.

What should an accessibility statement include?

I would include the organization’s commitment, the standard and scope used, the last review date, known limitations, available alternatives, how to request an accessible format or communication support, and how to provide feedback. For a physical location, add verified access facts and a direct contact. SEO iT’s accessibility statement uses that straightforward structure. Avoid broad claims the evidence cannot support.

What I would do next

First, confirm your employee range and legal scope. Then test one important customer journey from start to finish using only a keyboard. Fix anything that blocks the task, add a clear accessibility contact, and inventory the remaining templates, documents and vendors. If your business or non-profit has 20 or more employees in Ontario, put the December 31, 2026 reporting deadline on the calendar now.

If you want a practical second set of eyes on the website, I can help identify the search, content and conversion work that should be coordinated with a qualified accessibility review. Contact SEO iT and tell me which customer journey matters most. I’ll keep the conversation focused and low pressure.