Website accessibility means that people with disabilities — blind and low-vision visitors, Deaf and hard-of-hearing visitors, people who can’t use a mouse, people with cognitive and learning disabilities — can use your site as fully as anyone else. In Ontario it is also a legal duty for many organisations under the AODA. This guide explains who has to meet which standard, how the versions of WCAG differ, and a practical, six-step path to WCAG compliance that holds up after launch.
It concerns more people than most businesses expect. Statistics Canada’s 2022 Canadian Survey on Disability found that 27% of Canadians aged 15 and over — about 8 million people — have at least one disability. Add older visitors, people with temporary injuries and anyone on a phone in bright sun, and accessibility stops being an edge case: it is simply how a good website works.
Who Must Meet Website Accessibility Rules in Ontario
The Accessibility for Ontarians with Disabilities Act (AODA) sets its web rules in the Integrated Accessibility Standards Regulation. What applies to you depends on who you are:
- Public-sector organisations and organisations with 50+ employees in Ontario must make their public websites and web content conform to WCAG 2.0 Level AA, apart from live captions and pre-recorded audio description. The deadline for full conformance was January 1, 2021.
- Organisations with 20 or more employees must also file an accessibility compliance report with the province every three years.
- Smaller organisations aren’t bound by the website section — but the Ontario Human Rights Code still requires services to be accessible, and many public-sector and corporate buyers now ask suppliers for accessibility evidence before they sign.
- Federally regulated organisations — banks, telecoms, airlines and others — fall under the Accessible Canada Act, which requires accessibility plans, a feedback process and progress reports.
Enforcement sits with the Accessibility Directorate of Ontario. On conviction, fines can reach $100,000 for each day an offence continues for a corporation. More often, problems surface first as a complaint from a customer who couldn’t book, buy or apply — which is why accessibility is best treated as part of quality, not as a legal afterthought.
WCAG Compliance Explained: Versions and Levels
The Web Content Accessibility Guidelines (WCAG) are the international standard published by the W3C. They contain testable success criteria grouped under four principles — content must be perceivable, operable, understandable and robust — and each criterion has a level:
- Level A — the essentials. Without them, some people can’t use the page at all (no keyboard access, images without text alternatives).
- Level AA — the standard almost every law and policy references, including the AODA. It adds contrast, resizing, consistent navigation, clear focus, error help and more.
- Level AAA — the highest level. It is not expected for whole sites, because some criteria can’t be met for all content; teams adopt individual AAA criteria where they help.
There are three versions in use. WCAG 2.0 (2008) is what the AODA names. WCAG 2.1 (2018) added criteria for mobile use, low vision and cognitive disabilities — reflow at small widths, orientation, text spacing, contrast of icons and controls. WCAG 2.2 (2023) added nine more, including minimum target sizes and alternatives to dragging, and retired one obsolete criterion. Every version contains the one before it, so a site that meets WCAG 2.2 Level AA also meets 2.1 AA and 2.0 AA. That is the target we recommend: it covers the legal baseline and reflects how people actually use the web today. Our WCAG 2.2 guide explains each new criterion.
Two details often catch teams out. WCAG compliance applies to full pages — one inaccessible widget means the page doesn’t conform — and to complete processes: if one step of a checkout fails, the whole checkout fails.
A Six-Step Path to WCAG Compliance
Website accessibility isn’t a one-off fix. The organisations that stay compliant treat it as a process with a beginning — an audit — and no real end:
1. Audit the website
Start by measuring where the site stands against WCAG 2.2 Level AA, with automated scanning and manual testing — keyboard, screen readers, zoom, content. Automated tools alone miss most of what matters. Our digital accessibility audit guide walks through the process and what the report should contain.
2. Fix critical barriers on key journeys
Prioritise by impact, not by count. A keyboard trap in the checkout or an unlabelled field in the contact form blocks people completely; fix those first, on the journeys that matter most to your business: contacting you, buying, booking, applying, signing in.
3. Fix the templates and the design system
Most websites are built from a few templates and a shared set of components — buttons, menus, forms, cards, dialogs. Fixing an issue in the component fixes it on every page that uses it. This is also where long-term website accessibility is won: accessible colour tokens, visible focus styles, proper form patterns and semantic HTML built in once, then reused everywhere.
4. Fix content and documents
Content is where accessibility usually drifts. Write meaningful alt text, descriptive link text and clear headings; caption videos; and replace scanned or untagged PDFs with accessible versions or HTML pages. Give the people who publish content a short checklist — it prevents most new issues.
5. Publish an accessibility statement and a feedback process
An accessibility statement says which standard you aim for, what you know isn’t accessible yet and when it will be fixed, and how people can reach you if they hit a barrier. Under the AODA, organisations must also have an accessible feedback process and provide information in accessible formats on request, so the statement is a natural place to explain both.
6. Monitor with every release
Add automated accessibility checks to development, include keyboard and screen-reader tests in QA for new features, and re-audit after major redesigns. A yearly review keeps WCAG compliance from quietly eroding as content and features change.
What to Put in an Accessibility Statement
A good accessibility statement is short, honest and specific. It should cover:
- Your commitment and standard — for example, “we aim to meet WCAG 2.2 Level AA”.
- Current status — whether the site fully or partially conforms, and when it was last tested.
- Known limitations — what isn’t accessible yet (an older PDF library, a third-party booking widget), with workarounds and a target date for fixes.
- How to get help — a phone number, an email address and a contact form, and how quickly you respond.
- Accessible formats — how people can request information in another format, such as large print or an accessible document.
- Feedback — how comments are handled, and who is responsible.
Link it from the footer of every page, keep it up to date after each audit, and make sure the contact options it lists are monitored.
The Most Common WCAG Compliance Failures
In audits of business websites, the same problems appear again and again. Each one fails a specific WCAG success criterion:
- Low-contrast text — light grey copy, text over photos, placeholder text used as labels (1.4.3 Contrast).
- Images without useful alt text, and icon buttons with no accessible name (1.1.1 Non-text Content, 4.1.2 Name, Role, Value).
- Form fields without labels, and errors shown only in red (1.3.1, 3.3.1, 3.3.2, 1.4.1).
- Menus, pop-ups and carousels that don’t work with a keyboard, or trap focus (2.1.1, 2.1.2).
- Missing or invisible focus styles (2.4.7 Focus Visible).
- Headings chosen for their size rather than the page structure (1.3.1 Info and Relationships).
- Videos without captions and PDFs without tags (1.2.2 Captions, 1.3.1).
- Layouts that break at 200% zoom or on small screens (1.4.4 Resize Text, 1.4.10 Reflow).
Most of these come from a handful of shared components, which is why fixing templates and the design system (step 3) clears so many issues at once.
Designing for Website Accessibility From the Start
Retrofitting accessibility is always more expensive than building it in. When we design and build a site, accessibility is part of the brief from the first sketches:
- Colour and type are chosen with contrast measured, not guessed — 4.5:1 for body text, 3:1 for large text and controls — in both light and dark themes.
- Every interaction works with a keyboard, with a focus style people can actually see.
- Layouts reflow to a single column at narrow widths and stay usable at 200% text size.
- Motion respects “reduce motion” settings, and nothing flashes.
- Forms have visible labels, clear instructions and errors that explain the fix.
- Semantic HTML first, with ARIA only where native elements can’t do the job.
Done this way, accessibility costs very little extra — and the same qualities make a site faster, easier to use on a phone and easier for search engines to understand.
Website Accessibility Testing: What to Check Yourself
You can find the most obvious problems in a few minutes:
- Navigate your home page and contact form with only the keyboard. Can you see where you are, and reach everything?
- Submit a form with mistakes. Are the errors explained in words, next to the right field?
- Zoom to 200%. Does anything overlap, vanish or need sideways scrolling?
- Run WAVE or Lighthouse on your key pages and look at contrast and missing labels first.
- Turn on VoiceOver or NVDA and try to find your phone number or book an appointment.
If these turn up problems, a full audit will find more and tell you what to fix first.
Frequently Asked Questions
What is WCAG compliance?
WCAG compliance — strictly, conformance — means that every page and complete process on a website meets all the success criteria of a chosen WCAG version and level, most often WCAG 2.1 or 2.2 Level AA. The AODA requires WCAG 2.0 Level AA for the organisations it covers.
Is website accessibility required by law in Canada?
It depends on the organisation. In Ontario, the AODA requires public-sector organisations and organisations with 50 or more employees to meet WCAG 2.0 Level AA. Federally regulated organisations fall under the Accessible Canada Act. Human rights law requires accessible services more broadly, whatever the size of the business.
Does an accessibility plugin or overlay make a site compliant?
No. Overlays change how a page looks after it loads, but they don’t fix the underlying code, content or documents, and they can get in the way of the assistive technology people already use. WCAG compliance comes from fixing the site itself.
How long does it take to make a website accessible?
An audit of a small or medium site takes one to two weeks. Fixes depend on what it finds: issues in shared templates can often be resolved in days, while content-heavy sites with many documents take longer. New sites built accessibly from the start add little time at all.
Related Resources
- Digital Accessibility Audit: The 8-Step Process
- WCAG 2.2 Compliance Guide
- User Experience (UX)
- Web Design Toronto
Need help with website accessibility? PerfectPixels designs and builds accessible websites and audits existing ones against WCAG 2.2 Level AA. Contact us to talk about your site.
Further reading: How to make websites accessible — Government of Ontario.