About one in four Canadians aged 15 and older has at least one disability, according to Statistics Canada’s most recent Canadian Survey on Disability. Many of them rely on screen readers, keyboard navigation, captions, magnification or voice control to use the web. If your website doesn’t work with those tools, you’re turning away customers, candidates and partners often without realizing it.
In Ontario, accessibility isn’t only good practice; for many organizations, it’s the law. The Accessibility for Ontarians with Disabilities Act (AODA) sets standards for public websites and web content, and those standards are built on the Web Content Accessibility Guidelines (WCAG). This guide explains who must comply, what the requirements actually mean, the most common accessibility failures, how to test your website and how to build a practical compliance roadmap.
Quick answer: Under the AODA’s Integrated Accessibility Standards Regulation, designated public sector organizations and private or non-profit organizations with 50 or more employees in Ontario must make their public websites and web content conform to WCAG 2.0 Level AA, with limited exceptions such as live captions and pre-recorded audio descriptions. The requirement applies to websites the organization controls directly or through a contractual relationship that allows modification, and to web content published after January 1, 2012.
This article is general information, not legal advice. For decisions about your obligations, consult the Government of Ontario’s official AODA resources or a qualified adviser.
Key Takeaways
- Ontario organizations with 50 or more employees, plus designated public sector organizations, must meet WCAG 2.0 Level AA for public websites.
- Organizations with 20 or more employees must also file accessibility compliance reports on a set schedule.
- WCAG is built on four principles: perceivable, operable, understandable and robust.
- Automated tools catch only part of the problem; manual keyboard and screen reader testing is essential.
- Accessibility improvements usually improve SEO, conversion rates and usability for everyone.
What Is the AODA?
The Accessibility for Ontarians with Disabilities Act, passed in 2005, aims to make Ontario accessible for people with disabilities. Its standards cover customer service, information and communications, employment, transportation and the design of public spaces. Website requirements fall under the Information and Communications Standards within the Integrated Accessibility Standards Regulation (Ontario Regulation 191/11).
Who Must Make Their Website Accessible?
| Organization type | Website requirement |
|---|---|
| Ontario Government and Legislative Assembly | WCAG 2.0 Level AA (earlier deadlines applied) |
| Designated public sector organizations (municipalities, school boards, hospitals, colleges, universities and more) | WCAG 2.0 Level AA for public websites and web content |
| Private and non-profit organizations with 50 or more employees in Ontario | WCAG 2.0 Level AA for public websites and web content, required since January 1, 2021 |
| Private and non-profit organizations with fewer than 50 employees | Not subject to the website requirement, though other AODA obligations apply |
What counts as covered content?
The requirement applies to public internet websites and web content that an organization controls directly or through a contractual relationship that allows it to modify the product. It applies to web content published on a website after January 1, 2012. Exceptions include live captions and pre-recorded audio descriptions, and there are limited practicability exceptions.
Compliance reporting
Separately from website rules, private and non-profit organizations with 20 or more employees in Ontario must file accessibility compliance reports with the province on a recurring schedule. Check the Government of Ontario’s AODA reporting page for your current deadline.
Penalties
The AODA allows for administrative penalties and fines for non-compliance. Under the Act, corporations can face fines of up to $100,000 for each day an offence continues. Beyond legal exposure, inaccessible websites also create reputational risk and lost business.
What Is WCAG?
The Web Content Accessibility Guidelines are international standards published by the World Wide Web Consortium (W3C). WCAG 2.0 was published in 2008, WCAG 2.1 in 2018 and WCAG 2.2 in 2023. Later versions add success criteria, particularly for mobile users and people with low vision or cognitive disabilities.
AODA references WCAG 2.0 Level AA. Because newer versions build on 2.0, designing to WCAG 2.1 or 2.2 Level AA meets the AODA baseline and future-proofs your site.
The three conformance levels
| Level | Meaning | Typical target |
|---|---|---|
| A | Minimum accessibility; removes the most severe barriers | Required, but not enough on its own |
| AA | Addresses the most common barriers for most users | The legal and industry standard |
| AAA | Highest level; not always achievable for all content | Applied selectively where practical |
The four principles (POUR)
- Perceivable: Information must be presented in ways people can perceive text alternatives for images, captions for video, sufficient contrast.
- Operable: People must be able to use the interface keyboard access, enough time, no content that causes seizures, clear navigation.
- Understandable: Content and interfaces must be clear and predictable readable text, consistent navigation, helpful form errors.
- Robust: Content must work reliably with current and future assistive technologies valid code and proper use of HTML and ARIA.
The Most Common Website Accessibility Failures
1. Low colour contrast
WCAG Level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Light grey text on white backgrounds is one of the most frequent failures.
2. Missing or poor alternative text
Images that convey information need meaningful alt text. Decorative images should use empty alt attributes so screen readers skip them. “Image123.jpg” or “photo” is not alt text.
3. Keyboard traps and inaccessible menus
Everything must be usable with a keyboard alone: menus, sliders, pop-ups, forms, chat widgets and video players. Users must be able to move in and out of every component.
4. Invisible focus indicators
Keyboard users need a visible outline showing where they are on the page. Removing focus styles for design reasons is a common and serious barrier.
5. Unlabelled form fields
Every field needs a programmatic label. Placeholder text alone isn’t enough. Error messages must identify the problem and how to fix it.
6. Poor heading structure
Headings should follow a logical hierarchy (H1, then H2, then H3) and describe the content that follows. Screen reader users navigate by headings.
7. Vague link text
“Click here” and “Read more” repeated across a page tell screen reader users nothing. Link text should describe the destination.
8. Videos without captions
Pre-recorded videos with audio need accurate captions. Auto-generated captions usually need review and correction.
9. Inaccessible PDFs and documents
PDFs and documents published on your website are web content too. Scanned images of text, untagged PDFs and documents without structure are inaccessible.
10. Content that breaks when zoomed
Users must be able to resize text and zoom without losing content or functionality.
11. Auto-playing media and moving content
Carousels, animations and audio that start automatically must be controllable, users need to pause, stop or hide them.
12. Inaccessible third-party tools
Booking widgets, chatbots, maps, embedded forms and payment tools are part of your website experience. If you control them through your contract, they matter for compliance.
How to Test Your Website for Accessibility
Automated testing
Tools such as WAVE, axe DevTools and Lighthouse quickly flag issues like contrast failures, missing alt attributes and form label problems. They’re a valuable first pass, but automated tools can detect only a portion of WCAG issues. They can’t judge whether alt text is meaningful or whether a workflow makes sense.
Manual keyboard testing
Put the mouse away and navigate your site using Tab, Shift+Tab, Enter, Space and arrow keys. Can you reach every link and control? Is the focus always visible? Can you complete a form and close every pop-up?
Screen reader testing
Test key pages and journeys with screen readers such as NVDA (Windows), JAWS (Windows) and VoiceOver (macOS and iOS). Listen for missing labels, confusing reading order and unannounced changes.
Zoom and mobile testing
Zoom to 200% and beyond, test on mobile devices and check that content reflows without horizontal scrolling where required.
User testing
The most reliable insights come from people with disabilities using your site. Include them in testing for important journeys.
A Note on Accessibility Overlays
Accessibility overlays are widgets that promise instant compliance by adding a toolbar or automatically adjusting your site. They can’t fix underlying code, content or design problems on their own and don’t guarantee conformance with WCAG. Many accessibility experts and disability advocates caution against relying on them. Fix accessibility at the source instead.
Your AODA Website Compliance Roadmap
Step 1: Determine your obligations
Confirm your organization’s size and type, which websites and content are covered, and your reporting obligations.
Step 2: Audit your current website
Combine automated scans with manual testing of templates and key user journeys: home, services, contact forms, booking, checkout, careers and account pages.
Step 3: Prioritize fixes
Address barriers that block critical tasks first — forms, navigation, checkout and contact. Then fix sitewide template issues, which often resolve problems across hundreds of pages at once.
Step 4: Fix design, development and content
- Design: colour palettes with sufficient contrast, visible focus states, clear layouts and readable typography.
- Development: semantic HTML, proper labels, keyboard support and correct ARIA only where needed.
- Content: meaningful alt text, descriptive links, clear headings, captions and accessible documents.
Step 5: Address third-party tools and documents
Review plugins, widgets, embedded tools and PDFs. Ask vendors for accessibility conformance information and replace tools that can’t meet the standard.
Step 6: Publish an accessibility statement and feedback process
Explain your commitment, the standard you follow and how people can request information in an accessible format or report a barrier.
Step 7: Train your team
Content editors, designers, developers and marketers should know the basics so new content stays accessible.
Step 8: Maintain and monitor
Accessibility isn’t a one-time project. Build accessibility checks into publishing workflows, test new features before launch and re-audit regularly.
Accessibility and SEO: A Natural Partnership
Many accessibility best practices directly support SEO, AEO and conversion:
- Descriptive alt text helps image search and machine understanding.
- Logical headings help both screen readers and search engines understand structure.
- Captions and transcripts make video content indexable.
- Descriptive link text strengthens internal linking signals.
- Clear forms and navigation improve conversion rates for everyone.
Accessibility Beyond Ontario
Other Canadian jurisdictions have accessibility legislation too. The federal Accessible Canada Act applies to federally regulated organizations, and provinces including Manitoba, Nova Scotia and British Columbia have their own accessibility laws. Organizations operating across Canada or internationally should review the rules that apply in each market.
Frequently Asked Questions
The AODA website requirement applies to designated public sector organizations and to private or non-profit organizations with 50 or more employees in Ontario. Smaller organizations aren’t subject to that specific requirement, but accessible websites still reach more customers and reduce risk.
AODA requires WCAG 2.0 Level AA for covered public websites and web content, with exceptions for live captions and pre-recorded audio descriptions.
Designing to WCAG 2.1 or 2.2 Level AA meets the WCAG 2.0 Level AA baseline and adds improvements for mobile users and people with low vision or cognitive disabilities. It’s a sensible way to future-proof your website.
No plugin or overlay can guarantee compliance. Accessibility requires accessible design, development and content. Some tools help find issues, but fixes must be made in the site itself.
Costs depend on your site’s size, how it was built and the number of issues. Building accessibility into a new website is usually far more cost-effective than retrofitting an existing site.
Test before launching any new site or feature, check new content as it’s published and conduct a fuller audit at least annually or after major changes.
Build a Website Everyone Can Use
An accessible website reaches more people, performs better in search, converts more visitors and keeps your organization on the right side of Ontario’s accessibility laws. The best time to build accessibility in is at the start — and the second-best time is now.
Netxeno designs and develops accessible websites for organizations across Ontario, building to WCAG 2.1 and 2.2 Level AA and conducting accessibility audits and remediation for existing sites. Book a free accessibility review at netxeno.com/ and find out where your website stands.
