Quick answer
WCAG (Web Content Accessibility Guidelines) is the W3C's technical standard for making web content usable by persons with disabilities. It's organized into testable success criteria across three conformance levels — A, AA, and AAA — with Level AA at the current version, WCAG 2.2, serving as the practical compliance target for most organizations.
Why was WCAG created?
Before WCAG existed, "accessible website" meant whatever each developer or agency decided it meant. The W3C published the first version in 1999 to fix that: a single, technical reference point that turned a vague goal into something a team could actually test against.
The guidelines exist because accessibility barriers weren't random. The same patterns kept excluding the same groups of people — a screen reader user hitting an unlabeled form field, someone with low vision losing text against a low-contrast background, a person who can't use a mouse getting stuck in a dropdown menu with no keyboard path out. WCAG grew out of cataloguing those recurring failures and writing testable rules against each one, so a fix that worked for one site could be applied consistently everywhere else.
Why is WCAG important?
Without a shared, testable definition, "accessible" becomes whatever each team decides it means — which is exactly how inconsistent, unverifiable accessibility claims happen in the first place. WCAG matters because it turns a subjective goal into something a team can check against and be held to.
That's also what makes it usable across very different contexts at once. A developer can point to a specific success criterion during code review. A procurement officer can request a vendor's conformance level instead of taking a vague promise on faith. A court or regulator can point to the same document instead of arbitrating accessibility case by case. One technical reference doing all three jobs is what makes it more than a best-practice list.
Who should use WCAG?
WCAG isn't written for one role. Each of the groups below relies on it for a different reason, at a different stage of building or buying digital products.
Businesses
Use WCAG as the reference point for accessibility risk. It's what a legal claim gets measured against, and what a company can point to when demonstrating it took accessibility seriously before a complaint ever arrived.
Developers
Use it as an implementation checklist during actual coding: whether a custom dropdown is keyboard-operable, whether an image needs alt text or should be marked decorative, whether a color contrast ratio passes at the level the project targets.
Designers
Use it earlier in the process, before a line of code exists. Contrast ratios, touch target sizes, and reliance on color alone to convey meaning are all design decisions, and catching them in a mockup is far cheaper than catching them after launch.
Government organizations
Often have no choice in the matter. Many public-sector bodies are bound by law or procurement policy to meet a specific WCAG level, which makes it a compliance requirement rather than a voluntary best practice.
Content creators
Apply it at the level of individual pages and posts: writing meaningful link text instead of "click here," structuring headings so the page makes sense to someone navigating by heading alone, adding captions to video before it publishes.
What types of digital content does WCAG apply to?
WCAG's name says "web content," but in practice its reach extends to anything built with the same underlying technologies, and its principles get applied well beyond the browser.
Websites
WCAG's original and most direct territory — marketing pages, e-commerce storefronts, blogs, anything rendered in a browser as HTML, CSS, and JavaScript. This is why website audits are usually the most literal application of WCAG, with the fewest judgment calls.
Mobile applications
WCAG wasn't written for native apps, but its principles map on closely — touch target size, screen reader compatibility, and focus order translate almost directly. HTML-specific concepts like landmark regions get reinterpreted through each platform's own accessibility APIs instead.
PDFs and documents
Judged against the same principles, but the mechanism differs: an accessible PDF needs a tagged reading order, labeled headings, and embedded alt text. Accessibility usually depends on how the source document was authored, not a fix applied afterward.
Web applications
Dashboards and single-page apps apply WCAG to problems a static page doesn't have: focus management inside a modal, live regions announcing status changes, and custom components rebuilt to behave like the native controls they replace.
How is WCAG organized?
WCAG is structured as a hierarchy, and understanding the hierarchy is what makes the document usable instead of overwhelming. At the top sit four broad principles. Under each principle are guidelines, and under each guideline are the success criteria that actually get tested.
What are WCAG guidelines?
A guideline is the general goal that sits between a broad principle and a specific, testable rule — something like "provide text alternatives for non-text content" or "make it easier for users to see and hear content." Guidelines aren't tested directly; they exist to group related success criteria under one shared intent.
What are WCAG success criteria?
Success criteria are where WCAG becomes testable. Each one is a specific, pass-or-fail statement — "text has a contrast ratio of at least 4.5:1," "all functionality is operable through a keyboard interface" — assigned to a conformance level (A, AA, or AAA). This is the layer an auditor actually checks a page against.
What are the four WCAG principles?
Every guideline and success criterion in WCAG falls under one of four principles, often abbreviated as POUR. They're deliberately broad enough to cover the whole standard, but each one names a distinct way a product can fail.
Perceivable
Information has to be presented in a way people can actually perceive through some sense. A video with no captions fails this for a deaf user even if the rest of the page works correctly.
Operable
Every function has to be usable through more than a mouse. An interface that only responds to pointer input excludes anyone navigating by keyboard or switch device.
Understandable
Content and interface behavior have to be predictable. A form that submits on Enter in one place and requires a separate button elsewhere breaks this principle.
Robust
Code has to be interpretable reliably by current and future assistive technology. Using a <div> to act like a button instead of an actual <button> violates this even if it looks fine on the surface.
What are WCAG conformance levels?
WCAG success criteria are grouped into three conformance levels, and the difference between them is roughly how essential versus how demanding each requirement is — not just a difficulty scale.
Level A
Covers the most basic accessibility requirements — the failures that make content completely unusable for some group of users, not just harder to use. Missing alt text on a meaningful image or a keyboard trap inside a modal are Level A issues, because they block a task outright.
Level AA
The level almost every legal standard and procurement policy actually references, which makes it the practical target for most organizations. It covers things like a 4.5:1 contrast ratio for normal text, resizable text up to 200% without loss of content, and consistent navigation. When someone says a product "meets WCAG," they almost always mean Level AA.
Level AAA
The most stringent success criteria. WCAG itself notes AAA isn't recommended as a general policy requirement for entire sites, because some AAA criteria — like a 7:1 contrast ratio, or sign language interpretation for all video — aren't achievable for every type of content. AAA criteria are usually applied selectively rather than mandated site-wide.
What is the difference between WCAG 2.1, WCAG 2.2, and WCAG 3.0?
WCAG 2.1 and 2.2 are incremental updates to the same structure; WCAG 3.0 is a different kind of document, not just a version bump.
| What is the difference between WCAG 2.1, WCAG 2.2, and WCAG 3.0? | WCAG 2.1 | WCAG 2.2 | WCAG 3.0 |
|---|---|---|---|
| Status | Published W3C Recommendation | Current W3C Recommendation — the standard to build and test against today | Working Draft — not yet a finished standard |
| What changed | Added success criteria for mobile accessibility, low vision, and cognitive or learning disabilities, while staying backward-compatible with WCAG 2.0 | Added new success criteria (focus visibility, dragging interactions, accessible authentication) and removed one outdated criterion | Reorganizes guidance around outcome-based requirements and a graded scoring model, rather than a single pass/fail checklist |
| Conformance model | Same A / AA / AAA levels as WCAG 2.0 | Same A / AA / AAA levels as WCAG 2.0 and 2.1 | A different model (reported publicly as Bronze / Silver / Gold), still being finalized |
The practical takeaway is that WCAG 2.1 and 2.2 are both still active, compatible layers of the same standard — a site conforming to 2.2 also conforms to 2.1's requirements. WCAG 3.0 is a genuine rethink, still in Working Draft status, with a W3C Recommendation not expected before 2028 at the earliest. For any organization working on compliance today, WCAG 2.2 at Level AA remains the actual target.
How does WCAG influence accessibility laws around the world?
WCAG itself isn't a law anywhere — it's a technical standard published by the W3C. What varies by country is how directly a law or regulation actually points back to it.
| ADA | Never names WCAG directly; it requires "reasonable accessibility" without specifying a technical benchmark. U.S. courts and settlements have repeatedly pointed to WCAG 2.1 AA (and increasingly 2.2 AA) as what "reasonable" means in this context. |
|---|---|
| Section 508 | Applies to U.S. federal agencies and contractors, and does reference WCAG explicitly — the current refresh points to WCAG 2.0 Level A and AA as its technical baseline. |
| AODA | Ontario, Canada's accessibility law sets its own compliance schedule but points to WCAG 2.0 Level AA as the technical standard organizations need to meet. |
| European Accessibility Act | Doesn't cite WCAG by name; it works through EN 301 549, the EU's technical standard, which is built largely on WCAG's success criteria but also covers hardware, software, and documentation WCAG alone doesn't reach. |
How does WCAG improve user experience?
WCAG's requirements are usually framed as accommodations for persons with disabilities, but many of them improve the experience for everyone using a product, not just the audience they were written for.
Captions written for deaf users also help someone watching a video on a train with the sound off. Clear focus indicators built for keyboard users also help anyone who's momentarily lost track of where they are on a busy page. Sufficient color contrast written for low-vision users also helps anyone reading a phone screen in direct sunlight. This is usually called the "curb-cut effect," after physical curb cuts built for wheelchair users that turned out to help parents with strollers and travelers with rolling luggage just as much. WCAG compliance, approached well, isn't a separate accessibility layer bolted onto a product — it's a set of design decisions that raise the baseline usability of the product for the entire audience using it.
Frequently asked questions
Not directly, in most places. WCAG is a technical standard, not a law. Whether it functions as a legal requirement depends on the jurisdiction and the specific law referencing it — some, like Section 508 and the AODA, cite WCAG explicitly; others, like the ADA, reach it indirectly through case law and settlements.
Level AA is the level almost every legal standard and procurement policy references, and it's the practical target for most organizations. Level AAA is generally reserved for specific pages or features rather than applied site-wide, since some AAA criteria aren't achievable for every type of content.
Yes. A site conforming to WCAG 2.2 also satisfies WCAG 2.1 and 2.0's requirements, since each version added or refined criteria on top of the same underlying structure rather than replacing it.
No. WCAG 3.0 is still a Working Draft, with a W3C Recommendation not expected before 2028 at the earliest, and its conformance model isn't finalized. WCAG 2.2 at Level AA is the standard to build and test against now.
No. Automated scanners reliably catch structural issues like missing alt text or insufficient contrast, but they can't judge things like whether alt text is actually accurate or whether a reading order makes logical sense — those require manual testing by a person.
