WCAG Overview

What WCAG Is

The Web Content Accessibility Guidelines, usually shortened to WCAG, are the international technical standard for making digital content usable by people with disabilities. They are published by the World Wide Web Consortium, the organization that develops the core standards of the web, through its Web Accessibility Initiative.

WCAG describes what accessible content does, not how a particular product must be built. WCAG 2 is designed for web content, including static web pages and dynamic web applications. W3C also publishes WCAG2ICT, informative guidance explaining how WCAG principles and success criteria can be applied to non-web documents and software. That generality is deliberate. It allows the same standard to be referenced by many different laws, contracts, and organizational policies without being rewritten for each one.

WCAG is a technical standard. It is not, by itself, a law. It becomes a requirement in a specific context only when a law, regulation, contract, procurement rule, or internal policy adopts it and names a version and a conformance level. This distinction explains most of the confusion people encounter when they try to answer the question of whether their content is legally required to meet WCAG.

Who Develops WCAG

The World Wide Web Consortium develops WCAG through a public, consensus-based process. Drafts are produced by working groups whose membership includes disability organizations, assistive technology developers, researchers, government representatives, and industry participants. Documents progress through a series of public review stages before reaching the status of W3C Recommendation, which is the point at which a document is considered stable and ready to be referenced.

Because the process is public, the current status of any WCAG document can be checked directly at the W3C rather than inferred from secondary sources. This matters when a vendor, consultant, or article describes a version as current, required, or superseded.

The Four Principles: POUR

WCAG organizes its requirements under four principles, often remembered by the initials POUR.

Perceivable means that information and interface components must be presentable to users in ways they can perceive. Content that exists only as an image of text, a video without captions, or a color distinction that carries meaning on its own is not perceivable to everyone.

Operable means that interface components and navigation must be usable. A control that can only be reached with a mouse, a carousel that moves faster than a reader can follow, or a form that times out without warning creates an operability barrier.

Understandable means that information and the operation of the interface must be comprehensible. Predictable navigation, clear labels, plain error messages, and consistent behavior all support this principle.

Robust means that content must be reliable enough to work with a wide range of user agents, including assistive technologies, and to keep working as those technologies evolve. Well-formed markup and correctly exposed names, roles, and values support robustness.

The four principles are not scored separately. They are a way of organizing the guidelines and success criteria beneath them.

Guidelines and Success Criteria

Under each principle sit guidelines, which are broad goals, and beneath those sit success criteria, which are the testable statements that conformance is actually measured against.

Success criteria are written to be verifiable. Each one states a condition that content either meets or does not meet. They avoid naming specific technologies so that the same criterion can be applied to content built many different ways.

A success criterion is normative, meaning it is part of the standard itself. The supporting documents that accompany WCAG, including the Understanding pages and the Techniques documents, are informative rather than normative. They explain intent and show common ways of satisfying a criterion, but a technique is not the only acceptable method and failing to use a listed technique is not automatically a failure of the standard.

Conformance Levels A, AA, and AAA

WCAG sorts its success criteria into three conformance levels.

Level A covers the most fundamental requirements. Content that fails Level A generally presents serious barriers for one or more groups of users.

Level AA includes Level A and adds criteria that address common and significant barriers. Level AA is the level most frequently referenced by laws, regulations, and procurement policies, and it is the level most organizations are asked to meet.

Level AAA includes both earlier levels and adds the most demanding criteria. The W3C does not recommend requiring Level AAA conformance across an entire site as a general policy, because some Level AAA criteria cannot be satisfied for all types of content.

The levels are cumulative. Claiming Level AA conformance means meeting the Level A criteria as well. A claim of conformance also depends on meeting the conformance requirements in the standard, not only on passing individual criteria.

WCAG 2.0, 2.1, and 2.2

Three versions of WCAG 2 are in active use, and which one applies depends on what has adopted it.

WCAG 2.0 was published in 2008 and remains the version incorporated by some regulations.

WCAG 2.1 was published in 2018. It kept everything in WCAG 2.0 and added success criteria addressing mobile access, low vision, and cognitive and learning disabilities.

WCAG 2.2 reached W3C Recommendation status in October 2023 and was updated in December 2024. It adds nine success criteria beyond WCAG 2.1 and removes one criterion, 4.1.1 Parsing, which the W3C describes as obsolete.

The WCAG 2 versions are designed to be backward compatible. Content that conforms to WCAG 2.2 also conforms to WCAG 2.1 and WCAG 2.0. A newer version does not automatically replace an older one inside a regulation. A regulation continues to require the version it names until that regulation is changed.

A separate effort, sometimes referred to as WCAG 3, is in early development as a W3C Working Draft. It is not a standard, it is not a conformance target, and it should not be written into contracts or specifications.

Why Different Laws Reference Different Versions

Regulations incorporate a fixed version of a technical standard so that the legal requirement does not change every time the standard is updated. The result is that several versions of WCAG can be legally relevant at the same time in different contexts.

The Department of Justice rule for state and local government web content and mobile applications under Title II of the Americans with Disabilities Act specifies WCAG 2.1 Level AA. The Revised Section 508 Standards, which apply to federal agency information and communication technology, incorporate WCAG 2.0 at Level A and Level AA.

An organization that meets WCAG 2.2 Level AA also satisfies the earlier versions because of backward compatibility. That is one practical reason an organization may choose to design and procure to a newer version than the one it is legally required to meet, while still describing its legal obligation accurately.

WCAG and Assistive Technology

WCAG does not require the use of any particular assistive technology, and it does not test assistive technology itself. It describes the properties content needs so that assistive technology can work with it.

A screen reader can only announce a heading structure that exists. Speech recognition software can only activate a control that has an accessible name. A switch user can only reach a control that is keyboard operable. Magnification is only useful if the layout reflows without losing content or function.

This relationship is why accessibility work is usually more effective when it addresses the underlying content and code rather than adding a separate accessible version or an overlay layer on top.

WCAG does not determine which assistive technology an individual needs. Accessible design and individualized assistive technology serve different roles, and effective access may depend on both. For individualized technology and access-method decisions, see AT Assessment & Selection.

Common Misconceptions

Several assumptions come up often enough to be worth naming directly.

WCAG conformance is not established by an automated scanner alone. Automated tools are useful and necessary at scale, and they catch well-defined problems reliably, but a substantial share of success criteria require human judgment that a tool cannot exercise.

A statement that content is WCAG compliant is not a statement that it satisfies every accessibility law that might apply. Different laws cover different entities, adopt different versions, and are enforced through different mechanisms.

Meeting WCAG is not the same as being usable by every person with a disability. WCAG is a floor built on testable criteria, and usability testing with disabled users often reveals barriers that no criterion captures.

An accessibility statement, a certificate, a badge, or a vendor conformance report is a claim rather than proof. Each can be a useful input to evaluation, and each should be read critically and verified.

Using WCAG in Practice

WCAG is most useful when it is treated as a design and procurement input rather than an end-of-project audit.

Reading the success criteria alongside the Understanding documents makes the intent clearer than reading the criteria alone. Applying the standard to templates, design systems, and component libraries resolves the same defect everywhere it would otherwise be reproduced. Naming a specific version and level in contracts and requirements removes ambiguity later. Combining automated checks with manual testing, including keyboard-only navigation and screen reader review, produces a far more accurate picture than either method alone.

This page is an orientation rather than a testing tutorial. It describes what the standard is and how it is structured so that the more specific resources in this library make sense in context.

Related AssistiveTechnology.org Resources

For how WCAG relates to specific United States laws, see WCAG vs ADA vs Section 508. For the practical differences between the two most recently published versions, see WCAG 2.1 vs 2.2. For a general orientation to digital accessibility, see Digital Accessibility. For the Department of Justice rule as it applies to public entities, see ADA Title II Digital Accessibility for State and Local Governments, and for the K-12 context, see ADA Title II Digital Accessibility for Public Schools. For how conformance is checked in practice, see Accessibility Testing and Evaluation. For an introduction to assistive technology generally, see Assistive Technology 101, and for further reading across topics, see Resources.

Authoritative Sources

World Wide Web Consortium, Web Accessibility Initiative: WCAG 2 Overview, for version status and structure.

World Wide Web Consortium: Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, and the corresponding WCAG 2.1 and WCAG 2.0 Recommendations.

World Wide Web Consortium, Web Accessibility Initiative: What's New in WCAG 2.2.

U.S. Department of Justice, ADA.gov: Fact Sheet on the rule for web content and mobile applications of state and local government entities.

U.S. Access Board: Revised Section 508 Standards, including the incorporation of WCAG 2.0 Level A and Level AA for electronic content.

Last Standards Review

Last standards review: September 21, 2026. On that date the WCAG version statuses, the four principles and conformance levels, the count of success criteria added in WCAG 2.2, the removal of 4.1.1 Parsing, and the WCAG versions incorporated by the Department of Justice Title II rule and the Revised Section 508 Standards were verified against current W3C, Department of Justice, and U.S. Access Board sources.

About This Page

This page provides general educational information about the Web Content Accessibility Guidelines. It is prepared by The Accessibility Clinic Inc. as educational information only. It is not legal advice, and it does not guarantee that any specific website, application, document, or product meets a particular standard or legal requirement. Organizations should evaluate their own obligations in light of their specific circumstances and consult qualified counsel when needed. Standards and regulations change; the last standards review date above indicates when the statements on this page were most recently verified against primary sources.