If you run a small business in Ontario and someone mentions WCAG 2.1 AA, your first reaction is probably "what?" Fair. It sounds like something from a government compliance manual. And in a sense, it is. But the actual requirements are more practical than you'd expect, and most of them are things your website should be doing already.
The problem is that most sites aren't doing them. Not because the business owner doesn't care, but because nobody told them what "accessible" actually means in concrete terms. So let's fix that.
What WCAG actually is.
WCAG stands for Web Content Accessibility Guidelines. It's a set of standards published by the W3C (the organization that maintains web standards) that defines what it means for a website to be accessible to people with disabilities. Version 2.1, level AA, is the current benchmark that most legislation and best practices reference.
That's the textbook answer. Here's the practical one: WCAG 2.1 AA is a checklist of things your website should do so that people who are blind, deaf, have limited mobility, or have cognitive disabilities can still use it. That includes people using screen readers, people who can't use a mouse, people who need larger text, and people with colour vision deficiency.
In Ontario, about 2.6 million people have a disability. That's roughly one in five. If your website can't be used by one in five potential customers, that's not an edge case. That's a market segment.
The Ontario angle: AODA.
Ontario has the AODA, which requires organizations with 50 or more employees to make their websites conform to WCAG 2.0 Level AA. If you have fewer than 50 employees, you're not legally required to comply. But there are three reasons you should care anyway.
First, the threshold could change. Accessibility legislation trends in one direction: stricter. The federal Accessible Canada Act already applies to federally regulated businesses regardless of size. Ontario could follow.
Second, AODA complaints don't require a minimum employee count to file. If a customer with a disability can't use your site and decides to escalate, the conversation gets uncomfortable fast, regardless of whether you were technically required to comply.
Third, and most importantly: accessible websites perform better. That's not a feel-good statement. It's measurable.
The four principles (without the jargon).
WCAG organizes everything under four principles called POUR. The acronym is forgettable. The concepts aren't.
1. Perceivable: people can see or hear your content.
If someone can't see an image, they need a text description. That's alt text. Every product photo, every team picture, every banner image on your site should have a short, useful description. Not "IMG_4392.jpg". Not "image". Something like "Front view of the Riverside Cafe patio with string lights and outdoor seating."
Videos need captions. Audio content needs transcripts. Text needs enough contrast against its background to be readable. That last one catches more sites than you'd think. Light grey text on a white background looks sleek in a mockup. It's unreadable for anyone over 40 with less-than-perfect vision.
The standard: a contrast ratio of at least 4.5 to 1 for normal text. There are free tools that check this in seconds. If your "Book Now" button is light text on a medium-coloured background, it might be failing right now.
2. Operable: people can navigate and interact.
Not everyone uses a mouse. Some people navigate entirely by keyboard (Tab to move between elements, Enter to activate). If your dropdown menu, contact form, or booking widget can't be operated without a mouse, it's broken for those users.
This also means: no time limits that can't be extended. No content that flashes more than three times per second (seizure risk). And every interactive element needs a visible focus indicator so keyboard users can see where they are on the page. If you've ever hit Tab on a website and had no idea which element was selected, that site failed this one.
3. Understandable: people can figure out what to do.
Form fields need labels. Not placeholder text that disappears when you start typing. Actual labels that stay visible. Error messages need to say what went wrong and how to fix it. "Invalid input" helps nobody. "Please enter a valid email address" helps everyone.
Navigation should be consistent. If your main menu is at the top on the homepage but moves to a sidebar on the contact page, that's a problem. The page language should be declared in the code so screen readers pronounce words correctly. These aren't hard changes. They're just easy to overlook.
4. Robust: it works with assistive technology.
Your site needs to work with screen readers, voice control software, and other assistive tools. In practice, this means using proper HTML elements. A navigation bar should be a <nav>, not a <div> styled to look like one. A button should be a <button>, not a <span> with a click handler. Headings should use <h1> through <h6> in order, not just bold text in a large font.
This is where cheap template sites fail hardest. The visual result looks fine. The underlying code is a mess of generic containers that assistive technology can't parse. The site looks accessible. It isn't.
The business case.
Accessibility isn't charity. It's good business. Here's why.
Search engines reward it. Google can't see your images either. It reads alt text. Google can't click your dropdown menu. It follows semantic HTML. Almost everything you do to make a site accessible also makes it more visible to search engines. Proper heading structure, descriptive link text, fast load times, mobile responsiveness. The overlap between SEO best practices and WCAG compliance is about 80%.
Conversion rates improve. Clear labels, logical navigation, readable text, and obvious calls to action help everyone, not just users with disabilities. An accessible site is, by definition, easier to use. Easier-to-use sites convert better. The W3C Web Accessibility Initiative documents how accessible sites consistently outperform their inaccessible counterparts on engagement metrics.
You reach more people. Beyond the 2.6 million Ontarians with disabilities, think about situational limitations. Someone holding a baby and browsing one-handed. Someone in a loud job site watching your video without sound. Someone with a temporary injury using voice control. Accessibility isn't a niche. It's the full spectrum of how people actually use the web.
It protects you legally. Web accessibility lawsuits in North America have increased every year since 2018. Most target larger companies, but the legal landscape is shifting. Having an accessible site isn't just good practice. It's risk management.
Where to start.
You don't need to fix everything at once. Start with the items that have the biggest impact for the least effort.
| Fix | Effort | Impact |
|---|---|---|
| Add alt text to all images | Low | High (SEO + accessibility) |
| Check colour contrast on text and buttons | Low | High (readability for everyone) |
| Add visible labels to all form fields | Low | High (usability + compliance) |
| Ensure keyboard navigation works | Medium | High (core operability) |
| Use semantic HTML (nav, main, headings) | Medium | High (screen readers + SEO) |
| Add skip-to-content link | Low | Medium (keyboard users) |
| Add captions to videos | Medium | Medium (deaf/hard of hearing + noisy environments) |
| Declare page language in HTML | Low | Medium (screen reader pronunciation) |
There are free tools that catch the obvious issues. WAVE from WebAIM runs a scan on any page and highlights problems in plain language. Google Lighthouse (built into Chrome DevTools) includes an accessibility score. Neither catches everything, but both catch the low-hanging fruit.
What "compliant" actually looks like.
A WCAG 2.1 AA compliant site isn't visually different from a non-compliant one. You won't see it in the design. You'll see it in the details: every image has a description, every button works with a keyboard, every form field has a label, the text is readable, the code is clean, and the whole thing works with a screen reader.
It's not about adding a widget or an overlay. Those accessibility overlay products that promise one-line-of-code compliance don't work. They've been the target of more lawsuits than the sites they claim to fix. Real accessibility is built into the site from the ground up. It's part of the code, not bolted on top.
The short version.
WCAG 2.1 AA is a set of rules that make your website usable by everyone. Ontario businesses with 50+ employees are legally required to meet it. Smaller businesses aren't required to, but they benefit from it: better SEO, better usability, more customers, and legal protection.
Most of the fixes are straightforward. Alt text, colour contrast, form labels, keyboard navigation, clean code. You don't need a specialist for all of it. You just need someone who knows what to look for.
If you want to know where your site stands, get in touch. I'll take a look and tell you what's working, what's not, and what to fix first.