Four letters here, four letters there — the accessibility world runs on acronyms, and almost nobody outside it can tell you which ones are laws and which ones are just habits.
- a11y (the everyday practice) and AODA (the actual law) are the two poles of this whole topic — WCAG (the technical standard) is the bridge between them.
- a11y is a numeronym for “accessibility” (a + 11 letters + y), usually pronounced “ally” — shorthand for the practice, not a law or a standard.
- W3C is the international body that standardizes the web; its Web Accessibility Initiative (WAI) is the group that actually writes WCAG.
- AODA stands for the Accessibility for Ontarians with Disabilities Act — Ontario’s law — and its regulation names WCAG 2.0 Level AA as the website bar for large organizations, mandatory since January 1, 2021.
- ADA (US), the Accessible Canada Act (federal, narrow scope), and Section 508 (US procurement) are different rules from different governments — most Ontario businesses answer to none of the three.
What does a11y mean?
a11y is shorthand for the word “accessibility.” Nothing mysterious about it — it’s a numeronym, not an acronym: take the first letter (a), count the eleven letters sitting between it and the last letter (y), and you land on a11y.
Developers have been doing this to long, awkward words for decades. i18n means internationalization. l10n means localization. a11y is the one that escaped engineering circles entirely — it shows up in GitHub issue labels, conference names (#a11y), and job titles like “a11y engineer.”
Most people say it out loud as “ally,” and nobody’s fighting that pronunciation. It’s a genuinely nice bit of double meaning: practicing a11y well is, in a real sense, being an ally to people who rely on screen readers, switch devices, or magnification software to get through your site.
This piece is the terms companion to the complete AODA website accessibility guide — that’s the hub here for thresholds, the deadline, and penalties. This one just untangles what everyone actually calls all of it, and a11y is the term people ask about most.
Why is it called a11y, and is a11y the same thing as accessibility?
It’s called a11y because there are 11 letters between the “a” and the “y” in “accessibility” — and yes, a11y and “accessibility” mean exactly the same thing. There’s no meaning gap between them. The only real difference is where you’ll see each one used.
“Accessibility” is the word that shows up in law, in specifications, in anything formal — AODA, WCAG, the Accessible Canada Act, a client contract. a11y is the version that shows up everywhere else: Slack messages, ticket titles, blog posts like this one, a T-shirt at a conference. The numeronym habit comes out of the same software culture that gave us i18n and l10n — engineers compressing long words to save space in code, commit messages, and logs, long before it had anything to do with marketing or SEO.
Where people trip up is assuming a11y carries some separate technical meaning from “accessibility” — a specific method, maybe, or a certification. It doesn’t. It’s not a law, and it’s not a standard you can pass or fail. It’s just the word, worn down to five characters.
What are the W3C and WAI?
The W3C (World Wide Web Consortium) is the international organization that sets the technical standards the web runs on — HTML, CSS, and yes, accessibility. It’s not a government body, and it doesn’t belong to any single company. It’s vendor-neutral by design, which is exactly why its standards get adopted worldwide instead of just in one country.
Inside the W3C sits the Web Accessibility Initiative, or WAI — the working group that actually researches and writes the accessibility guidelines. When someone says “the W3C’s accessibility standard,” WAI is the team that produced it. You can see their work directly at w3.org/WAI.
Neither one enforces anything on your business directly. No inspector from the W3C is ever showing up at your office. They write the standard. Whether that standard becomes mandatory for you depends entirely on which country’s laws you operate under — which is exactly where AODA comes in.
What is WCAG, and how does a11y connect to it?
a11y vs WCAG, plainly: a11y is the practice, WCAG is the checklist that grades it.
WCAG — Web Content Accessibility Guidelines — is the technical standard WAI publishes. It’s the “how”: specific, testable rules a website has to meet to be usable by people with disabilities.
It comes in versions (2.0, 2.1, 2.2, each adding more criteria) and conformance levels (A, AA, AAA, each stricter than the last), organized under four principles the field shortens to POUR — Perceivable, Operable, Understandable, Robust.
Ontario’s regulation still points at WCAG 2.0 specifically — 2.1 and 2.2 exist and are stricter, but the law hasn’t been updated to them, so 2.0 Level AA is the legal bar here.
The full breakdown of what WCAG 2.0 Level AA requires lives in its own piece, with real fix examples for Ontario businesses.
Here’s where a11y fits in concretely: a11y is the practice, and WCAG is the checklist that tells you whether the practice actually worked. A developer doing “a11y work” all day — fixing contrast, labeling forms, testing with a keyboard — is, in effect, building and testing against WCAG’s criteria, whether or not the ticket ever says the word WCAG. On its own, WCAG is just guidance. It becomes mandatory only once a law points at it, and in Ontario, that law is AODA.
What does AODA stand for, and who does it apply to?
AODA stands for the Accessibility for Ontarians with Disabilities Act — Ontario’s law. It’s the “must,” and unlike WCAG, it’s provincial legislation (S.O. 2005, c.11) with real deadlines and real fines attached.
Who it applies to scales with employee count, and getting that split right matters more than almost anything else in this topic. Under 20, you’re clear of both duties. Cross 20 and you’re filing a report — nothing more, yet. Cross 50 and the report gets a partner: your public website now has to conform to WCAG 2.0 Level AA, a duty live since January 1, 2021. I walk through whether AODA applies to your business tier by tier with worked examples, and the mechanics of the December 31, 2026 AODA deadline in its own explainer.
What’s the difference between WCAG and AODA?
WCAG is a technical standard. AODA is a law. That’s the whole difference in one sentence, and the relationship between them is a short chain worth memorizing: W3C/WAI writes WCAG (the standard) → AODA (the law) points at WCAG → a11y is the everyday practice of actually meeting it.
Nobody hands you a chart when these terms start flying around in a meeting, so here’s one.
| Term | What it is | Who runs it | Who it affects |
|---|---|---|---|
| W3C / WAI | International standards body / its accessibility division | Global, vendor-neutral consortium — not a government | Anyone building on the web, worldwide — voluntarily |
| WCAG | Technical standard (the “how”) | Written by WAI, part of the W3C | Whoever a law or contract says has to follow it |
| AODA | Provincial law (the “must”) | Government of Ontario | Ontario businesses and non-profits, scaled by employee count |
| a11y | Everyday practice / shorthand for the discipline | No one — it’s a term of art, not an authority | Anyone doing the work: developers, designers, content teams |
Once that chain clicks, most of the confusion clears up on its own. AODA didn’t write its own rulebook for what an accessible website looks like — it borrowed WCAG wholesale, at Level AA, and made following it mandatory for the organizations it covers.
Is my website AODA compliant?
There’s no badge or certificate that answers this for you — the only way to know is to actually test your site against WCAG 2.0 Level AA’s success criteria, using both automated scanning and manual testing with real assistive technology.
A few checks you can genuinely run yourself this week: tab through your homepage with no mouse and see if you can reach and operate everything; run a contrast checker against your body text and buttons; try your top pages with a screen reader and listen to how much of it actually makes sense. Automated tools like Lighthouse, axe, or WAVE are a decent first pass, but the honest, widely-shared position in the accessibility field is that automated scans catch only a minority of real WCAG issues — the rest surface only under manual testing.
This is also exactly why a $50-a-month widget claiming to auto-fix your compliance doesn’t hold up under scrutiny. I go deep on whether an accessibility overlay makes you compliant, including a federal regulator’s $1 million finding against one vendor for making that exact claim.
AODA vs ADA: what’s the difference?
AODA is Ontario provincial law. ADA — the Americans with Disabilities Act — is US federal law. Different countries, different governments, different enforcement mechanisms entirely, even though both end up pointing businesses toward the same technical target: WCAG.
ADA doesn’t name WCAG explicitly the way AODA’s regulation does, but US courts have consistently treated WCAG as the de-facto standard for what an accessible website looks like, and ADA claims are the driver behind the majority of the 5,000-plus digital accessibility lawsuits filed in the US in 2025. It applies to you directly only if you’re a US entity, or doing enough business with US customers to draw real legal exposure.
Two more names round out what people search under “web accessibility standards Canada,” and neither is what typically governs an Ontario small or mid-sized business (SME). The Accessible Canada Act (ACA) is Canada’s federal accessibility law, but it binds federally regulated entities only — banks, telecom carriers, airlines, interprovincial transportation. Most Ontario small and mid-sized businesses aren’t covered by it at all; they fall under AODA. And for the sake of completeness: what is 508 compliance? Section 508 is a narrower US federal procurement rule requiring government agencies, and vendors selling to them, to buy accessible technology — it has nothing to do with an Ontario business unless you’re selling into the US federal government specifically.
What is ARIA, and where does it fit in?
ARIA — Accessible Rich Internet Applications — is a W3C spec, published by WAI alongside WCAG. Plainly: it’s the code labels that tell a screen reader what an element actually is, when the underlying HTML doesn’t already say so on its own.
A native <button> announces itself as a button for free. A <div> styled to look like one doesn’t — ARIA is the patch that tells assistive tech “treat this like a button,” role and state included.
It’s also the part of accessibility most often done badly. Add role=”button” to a div without the keyboard handling that goes with it, and you’ve told a screen reader something the page doesn’t actually deliver. The field has a blunt way of putting this: no ARIA is better than bad ARIA. Where that goes wrong in practice — including how bolted-on overlay widgets abuse ARIA at scale — is covered in the overlay piece linked above.
Who actually has to think about each of these, day to day?
These terms sound abstract until you attach them to an actual person’s Monday morning. Four quick examples, four different acronyms.
- A dental clinic owner in Guelph, 55 employees. She doesn’t care what a numeronym is. She cares about AODA — it’s the law that says her website has to meet WCAG 2.0 Level AA, and it’s the law with fines attached to her business’s name if she ignores it.
- The developer on her web team. She lives in a11y, WCAG, and ARIA every week — running contrast checks, tabbing through forms, fixing the div-pretending-to-be-a-button pattern before anything ships. AODA is why the work exists; WCAG is what she’s actually building against.
- An e-commerce store in Mississauga that also ships to US customers. AODA still applies at home, but selling into the US adds a second layer of exposure — ADA lawsuits target e-commerce sites disproportionately, and roughly 70% of 2025’s US accessibility suits, per the same UsableNet report, landed on stores exactly like this one.
- The digital team at a bank. Banks are federally regulated, so on top of whatever else applies, the Accessible Canada Act binds them directly — a scope almost no Ontario small business shares.
What are Ontario’s website accessibility requirements, and which of these actually apply to you?
If you’re a typical Ontario business, the answer is short: AODA is your law, WCAG 2.0 Level AA is your technical bar, and a11y is the practice that gets you there. ADA, ACA, and Section 508 usually don’t touch you at all — unless you’re federally regulated, or you sell enough into the US that an ADA claim becomes a real risk rather than a hypothetical one.
That’s a shorter list than the acronym soup makes it sound, and it’s the honest answer to “accessibility compliance Ontario” once you strip out everything that doesn’t actually apply. One law. One standard behind it. One term for the daily work of meeting both. On the big media builds I worked on — Sportsnet.ca’s enterprise migration among them — WCAG wasn’t a nice-to-have tucked into a backlog. It was in the acceptance criteria, and it got audited before anything shipped. That’s the same bar worth bringing to a business a fraction of that size, because the law doesn’t scale the standard down — only the reporting duty.
For the full mechanics behind all of this — thresholds, the deadline, penalties, plugins versus real fixes — the complete AODA website accessibility guide is the hub piece this whole cluster sits under. If your stack is WordPress specifically, AODA compliance on WordPress covers where popular themes and page builders quietly fail. And if you’d rather have someone turn all of this into an actual fix list for your site, that’s what jbe.works’ accessibility service does — a free scan will tell you where you currently stand.
Frequently asked questions
Quick answers to the acronym questions that come up most.
Is your site costing you customers?
Enter your website and get a free 60-second performance, SEO & accessibility report.
~60 seconds · No login