The Accessibility for Ontarians with Disabilities Act is Ontario law, and the website part of it is narrower than most Toronto business owners have been told. Agencies sell AODA compliance to companies it does not apply to, and skip it entirely for companies where it does. Both are worth avoiding.
Who the website requirement actually covers
Section 14 of the Integrated Accessibility Standards Regulation requires internet websites and web content to conform with WCAG 2.0 Level AA. The requirement applies to designated public sector organisations and to large private and non-profit organisations, which the regulation defines as those with 50 or more employees in Ontario.
A private Ontario business with fewer than 50 employees is not caught by the website conformance requirement. That is the specific answer that agencies selling compliance packages tend to leave vague.
Two qualifications matter. First, AODA’s other obligations — accessible customer service, accessible formats on request, employment standards — have different and broader thresholds, so “the website rule does not apply to us” is not “AODA does not apply to us”. Second, the threshold is a count of employees, and a company that grows past 50 acquires the obligation without anybody sending a letter about it.
If your organisation is near the line, or you are unsure of your own obligations, that is a question for a lawyer rather than a web agency. What follows is what the standard means in practice, which is the part we can speak to.
What Level AA means in practice
Stripped of the specification language, an accessible site is one that can be operated without a mouse, read aloud in a sensible order, understood without relying on colour, and used at 200% zoom without content disappearing off the side.
Concretely, that comes down to a fairly short list:
- Contrast. Body text at a contrast ratio of at least 4.5:1 against its background, large text at 3:1. Light grey on white fails, and it is everywhere.
- Real headings, in order. An h1, then h2s, then h3s, without skipping levels. Screen reader users navigate by heading; a page styled to look like headings without using them is a page with no navigation.
- Labelled form fields. Every input associated with a real label. Placeholder text is not a label — it disappears the moment somebody types.
- Meaningful link text. “Read more” repeated eleven times is useless when links are listed out of context. The link should describe its destination.
- Visible focus. Keyboard users need to see where they are. Removing focus outlines because they look untidy is the single most common accessibility failure in custom design work.
- Alt text that carries meaning. Descriptive where the image conveys information, deliberately empty where it is decorative. Both are correct in their place.
- Keyboard operability. Menus, dialogs, sliders, accordions and forms all reachable and operable with Tab, Enter and Escape, with focus handled properly when a dialog opens.
- Captions on video, and no content that flashes.
WCAG 2.1 and 2.2 add further criteria — target sizes, focus appearance, dragging alternatives, and accessible authentication. AODA references 2.0, but building to 2.2 AA is sensible: it is where the standard is going, and the added criteria are mostly things a careful build does anyway.
Why overlay widgets do not solve it
Accessibility overlays — scripts that add a floating accessibility button and promise compliance in a line of JavaScript — are heavily marketed to exactly the businesses reading this. Accessibility practitioners and disability advocacy organisations have criticised them consistently and at length, and their use has not prevented complaints or legal claims against the sites using them.
The reason is structural rather than commercial. Accessibility is a property of the markup: whether a button is a button, whether a field has a label, whether the heading order reflects the document. A script loaded after the page cannot reliably infer any of that, and screen reader users frequently report that overlays interfere with the assistive technology they already use and have configured.
An overlay is a purchase that produces a compliance-shaped feeling. It does not produce compliance.
How accessibility is actually tested
Automated testing with a tool such as axe-core catches somewhere between a third and a half of real issues — contrast, missing labels, missing alt attributes, invalid ARIA. It is fast, it runs in continuous integration, and it should run on every build.
The remainder needs a human. A keyboard-only pass through the real journeys — navigate the menu, open the mobile menu, complete the enquiry form, trigger and dismiss any dialog, reach the footer — finds the issues automation cannot see, principally focus management and whether the tab order matches what the page looks like.
For reference, incepticode.com is tested with axe-core against WCAG 2.1 and 2.2 A and AA across every page template, at both desktop and mobile widths and with menus and form errors open, plus a keyboard-only path — at zero issues at any severity. The test script lives in the repository and runs before every deploy, which is the only way a measurement like that stays true.
The business case, separate from the legal one
Roughly one in five people has a disability, and the proportion is higher among older buyers — who, for most Toronto service businesses, are the ones with money to spend on a renovation, a clinic visit or a legal matter.
Beyond that, the overlap with everything else is close to total. Sufficient contrast helps anybody reading a phone in sunlight. Real headings and semantic markup are what makes a page crawlable and quotable by search engines and answer engines. Labelled fields reduce form abandonment for everyone. Keyboard operability is what makes a site usable on a laptop with a broken trackpad.
Accessibility work is not a tax on good design. It is most of what good design already is, written down.
Where to start
If a site already exists, run an automated scan and a keyboard pass, and fix contrast, labels and focus outlines first — they are the highest-frequency failures and usually the cheapest to correct.
If a site is being built, specify WCAG 2.2 AA in the scope and ask how it will be tested. An agency that answers with the name of a tool and a description of a keyboard pass is doing the work. An agency that answers with the name of an overlay product is not.
InceptiCode builds to WCAG 2.2 AA as standard and audits existing sites against it — details on the accessibility page.