The Web Content Accessibility Guidelines (WCAG) are the international standard for making websites usable by people with disabilities. Published by the W3C, they organize accessibility into four principles — Perceivable, Operable, Understandable, Robust — and three conformance levels (A, AA, AAA). In the U.S., courts treat WCAG 2.1 Level AA as the benchmark for ADA website cases.
What WCAG actually is
WCAG (pronounced “wuh-cag”) is not a law. It’s a set of testable success criteria maintained by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative (WAI) — the same body that sets standards for HTML and other core web technologies. You can read the guidelines directly at w3.org/WAI.
The point of WCAG is to make the web work for everyone, including people who:
- are blind or have low vision and use a screen reader (NVDA, JAWS, or VoiceOver) or screen magnification;
- are deaf or hard of hearing and rely on captions and transcripts;
- have motor disabilities and navigate by keyboard only, switch device, or voice control;
- have cognitive, learning, or neurological disabilities and need clear, predictable, readable content.
These tools — screen readers, switches, voice software, magnifiers — are called assistive technology. WCAG describes, in concrete and checkable terms, what your site must do so that assistive technology can interpret it correctly. When the standard is met, the experience holds up. When it isn’t, real people get locked out — and, increasingly, that gap turns into a demand letter or lawsuit.
WCAG is the “how.” The ADA is the “you must.” Most U.S. accessibility obligations point back to WCAG even when the law never says the word.
WCAG versions, briefly
WCAG has evolved over time, and the version number matters because legal references and audit reports pin to specific ones.
| Version | Released | Status for businesses |
|---|---|---|
| WCAG 2.0 | 2008 | Foundational; superseded but still referenced in older settlements and Section 508. |
| WCAG 2.1 | 2018 | The de facto standard cited in most ADA cases and the 2024 DOJ rule for state/local government. |
| WCAG 2.2 | 2023 | Newest version; adds criteria (e.g., focus appearance, dragging alternatives). Fully backward-compatible with 2.1. |
| WCAG 3.0 | Draft | A future rewrite, years from finalization. Not something to build to yet. |
The practical guidance for a small business is simple: build to WCAG 2.1 AA at minimum, and to WCAG 2.2 AA where you can. Because 2.2 includes everything in 2.1, meeting 2.2 automatically covers the version courts still cite most. We break the differences down in WCAG 2.2 vs 2.1.
A quick note on a related standard: Section 508 is the U.S. federal procurement rule that requires accessible technology, and it now incorporates WCAG 2.0 AA by reference. If you sell to government agencies, you’ll likely be asked for a VPAT (Voluntary Product Accessibility Template) documenting how your product measures up. For how the law, the federal procurement rule, and the standard fit together, see our breakdown of how the ADA, Section 508, and WCAG relate.
POUR: the four principles behind every rule
Every WCAG success criterion ladders up to one of four principles, known by the acronym POUR. This is the most useful mental model for a business owner, because it tells you what kind of problem you’re looking at without drowning you in 50+ individual criteria.
Perceivable
Users must be able to perceive the content — it can’t be invisible to all of their senses.
- Alt text on images so screen readers can describe them.
- Captions and transcripts for video and audio.
- Sufficient color contrast between text and background so low-vision users can read it.
- Not relying on color alone to convey meaning (“the items in red are sold out” fails).
Operable
Users must be able to operate the interface — every function has to work, not just the mouse-driven path.
- Full keyboard navigation: everything clickable must be reachable and usable with the Tab, Enter, and arrow keys, with no “keyboard traps.”
- Visible focus indicators so keyboard users can see where they are.
- Enough time to read and use content; no flashing that could trigger seizures.
- Clear, descriptive links and skip-to-content links.
Understandable
Content and operation must be understandable — predictable and clear.
- Readable text and a declared page language.
- Forms with proper labels, clear instructions, and helpful error messages.
- Consistent navigation and predictable behavior — nothing that changes context on you unexpectedly.
Robust
Content must be robust enough to work reliably with current and future assistive technology.
- Clean, valid, semantic HTML.
- Correct use of ARIA (Accessible Rich Internet Applications) roles and labels — and, just as important, not misusing ARIA, which often makes things worse.
- Proper heading structure and landmarks so users can understand and jump around the page.
Want the deeper version? Read the full breakdown of the POUR principles.
Conformance levels: A, AA, and AAA
WCAG sorts its success criteria into three levels of strictness. Each higher level includes the ones below it.
| Level | What it covers | Who needs it |
|---|---|---|
| A | The most basic, non-negotiable accessibility. A site that fails Level A is unusable for many people. | The floor — necessary but not sufficient. |
| AA | A strong, achievable standard that removes the most common, significant barriers. | The target for nearly every business. This is the level courts and the DOJ expect. |
| AAA | The strictest level (e.g., the highest contrast ratios, sign-language video). | Specialized contexts; W3C itself says AAA isn’t required for entire sites. |
The headline: when people say a site should be accessible, they almost always mean Level AA. Demand letters, settlements, and the 2024 DOJ rule for public entities all reference WCAG 2.1 (or 2.2) Level AA — not A, and not AAA. Aim for AA across your whole site and treat individual AAA criteria as nice-to-haves where they’re easy wins. We unpack the trade-offs in WCAG conformance levels A/AA/AAA.
Why WCAG matters legally (without being the law)
Here’s the part that trips up most business owners. The Americans with Disabilities Act (ADA), and specifically Title III, prohibits discrimination by “places of public accommodation.” Federal courts have repeatedly applied this to business websites, and the Department of Justice has stated publicly that the ADA covers the web. But the ADA statute does not name WCAG, and there is still no standalone federal regulation specifying WCAG for private businesses.
So why does WCAG dominate? Because when a court or a plaintiff’s attorney needs to decide whether a website is “accessible,” they need an objective, testable standard — and WCAG 2.1 AA is the one everyone reaches for. It shows up in settlement agreements, consent decrees, and the 2024 DOJ rule that puts state and local governments on firm WCAG 2.1 AA deadlines.
The practical takeaway: thousands of ADA web lawsuits are filed each year, the large majority aimed at small and mid-sized businesses, and the standard you’ll be measured against is WCAG. Meeting it is the single best way to lower your risk. For the full legal picture, see our pillar on ADA website compliance.
This page is general information, not legal advice. If you’ve received a demand letter or have specific legal exposure, consult an attorney who handles ADA matters.
How you actually meet WCAG
Knowing the standard is one thing; conforming to it is another. The path looks like this:
-
Audit. Test your site against WCAG 2.1 AA. Automated scanners are a useful first pass but catch only an estimated 30–40% of real issues. The rest require manual testing — a person operating the site with a screen reader and keyboard. A proper website accessibility audit combines both and produces a prioritized list of failures mapped to specific success criteria.
-
Remediate. Fix the findings in the code: correct heading structure, add and refine alt text, fix contrast, label forms, repair focus order, and apply ARIA only where native HTML can’t do the job. This hands-on work is accessibility remediation — the part that actually makes a site conform.
-
Document. Produce an accessibility statement and, if you sell to enterprise or government buyers, a VPAT / Accessibility Conformance Report that records your conformance level.
-
Maintain. Sites change. New pages, plugins, and content can introduce new barriers, so periodic re-testing keeps you conformant over time.
Why overlays can’t deliver WCAG conformance
You’ve probably seen the pitch: install one line of JavaScript, get an overlay widget — the little accessibility toolbar in the corner — and your site is “compliant.” It doesn’t work that way.
Overlays sit on top of your site at runtime. They can toggle a few cosmetic settings (bigger text, a contrast mode), but they do not fix the underlying HTML, ARIA, labels, or content that WCAG actually measures. A screen reader still encounters the same broken structure. That’s why businesses running overlays have still been sued, and why hundreds of accessibility professionals have publicly stated overlays don’t deliver conformance.
Real WCAG conformance is structural. It lives in the code, and it gets there through manual remediation — not a widget. If you’re weighing your options, read do accessibility overlays work? for the honest answer.
Where to go from here
WCAG is a big standard, but you don’t have to absorb all of it to act. Start by understanding the level you need (2.1 AA), the four principles (POUR), and the gap between your current site and that target. The spoke pages in this section go deeper on each piece — the POUR principles, the A/AA/AAA conformance levels, what WCAG 2.1 AA covers, and how WCAG 2.2 differs.
Ready to find out where you stand? Run a free accessibility scan using the button on this page — it checks your site against WCAG 2.1 AA and shows you exactly where the gaps are, no overlay required.
For deeper reading straight from the source, the W3C’s Web Accessibility Initiative and WebAIM are both excellent, plain-language references, and ADA.gov covers the law itself.