WCAG explained without the technical jargon

Introduction

For many people, the first encounter with WCAG is not especially inviting.

Open the standard and you quickly find principles, guidelines, success criteria, conformance levels, techniques, exceptions, definitions, and references to other documents. The information is useful, but without a mental model for how the pieces fit together, WCAG can look like an enormous technical checklist that only accessibility specialists are expected to understand.

That is not the most useful way to approach it.

At its core, WCAG provides a structured way to identify accessibility barriers and define outcomes that can be evaluated consistently. It helps designers, developers, content teams, testers, and organizations move from a broad goal such as “make this website accessible” to more specific questions about whether people can perceive information, operate controls, understand what is happening, and use the product with different technologies.

The acronym stands for Web Content Accessibility Guidelines, but understanding the name is only the beginning. The more important question is how the standard is organized and what it is actually trying to achieve.

This article focuses on WCAG 2.2, the latest version of WCAG 2 recommended by W3C for current accessibility work. Rather than working through dozens of individual requirements, we will look at the structure behind them: the four principles, the role of success criteria, the meaning of A, AA and AAA, what changed in WCAG 2.2, and why conformance is important without being the same thing as a perfect user experience.

If you are completely new to the subject, our introduction to web accessibility provides useful context before getting into the standard itself.

What does WCAG mean?

WCAG stands for Web Content Accessibility Guidelines.

It is an international web accessibility standard developed through the World Wide Web Consortium, or W3C. It applies to web content and digital experiences and provides requirements intended to make them more accessible to people with disabilities.

WCAG is not a piece of software, an automated testing tool, or a certification that W3C awards to websites. It is also not, by itself, a universal law. Different countries and organizations may reference WCAG in legislation, procurement rules, contracts, or internal policies, but the standard itself is a technical framework.

That distinction matters because WCAG is sometimes discussed as though it were a badge a website either possesses or does not possess. In practice, the standard is more useful when treated as a common language for identifying barriers and defining what needs to be true for particular accessibility requirements to be satisfied.

A requirement about keyboard access, for example, is not there because keyboards are preferred over mice. It exists because some people cannot use a pointer device and must still be able to reach and operate the interface.

A requirement about text alternatives is not about adding metadata for its own sake. It exists because visual information may need to be communicated in another form.

The technical wording describes a testable expectation. The accessibility barrier explains why that expectation exists.

Who creates WCAG?

WCAG is developed through the World Wide Web Consortium (W3C) and its Web Accessibility Initiative (WAI).

The work involves the Accessibility Guidelines Working Group, with participation from people and organizations with expertise in accessibility, standards, technology, research, and disability-related needs.

This collaborative process is important because web accessibility does not belong to a single browser, technology company, government, or profession. The web is used internationally, across many technologies and by people with very different ways of perceiving and interacting with digital content.

WCAG therefore aims to define requirements in a way that is not tied too closely to one implementation or product. The standard describes the outcomes that need to be achieved, while supporting documents such as Understanding WCAG and Techniques for WCAG provide additional explanation about how those outcomes may be met.

That separation is one reason the standard can remain relevant while technologies change.

The four principles: POUR

WCAG 2.2 contains 13 guidelines, organized beneath four principles: Perceivable, Operable, Understandable, and Robust.

Together they are often remembered through the acronym POUR.

The principles are broad by design. They do not tell a team exactly how to build a form, design a navigation menu, or code a modal. Instead, they describe four fundamental conditions an accessible digital experience needs to support.

Perceivable

The first question is simple: can people get the information?

Content cannot be useful if it is presented in a form a person cannot perceive.

For someone who cannot see an image, that may mean providing an appropriate text alternative. For someone who cannot hear audio, important spoken information may need captions or another text equivalent. For someone with low vision, text and controls may need sufficient contrast and the ability to adapt when content is enlarged.

Perceivable does not mean that everyone must experience information in exactly the same way. It means that important information should not depend on only one sensory presentation when another form is needed.

Operable

The next question is: can people interact with the experience?

A control that looks perfectly clear but cannot be reached without a mouse may be unavailable to someone who navigates by keyboard. A small target that demands precise pointer movement can create a barrier for a person with limited motor control. An interaction that moves or changes too quickly may become difficult or impossible for someone who needs more time.

Operable covers the mechanics of interaction: navigation, keyboard access, timing, focus, gestures, movement, and the ways users control what happens on the page.

The central idea is that the interface should not assume one particular method of input.

Understandable

Accessibility also depends on whether people can understand the information and the behavior of the interface.

Clear instructions, meaningful labels, predictable navigation, useful error messages, and consistent interaction patterns all contribute to this principle.

An interface can technically expose every control to assistive technology and still be difficult to use if the language is confusing or if the product behaves unpredictably.

Understandable reminds us that accessibility is not only about whether information and controls are available. People also need enough clarity to know what those things mean and what will happen when they interact with them.

Robust

Robust is often the least intuitive of the four principles.

A useful way to think about it is: can different technologies interpret the experience reliably?

Web content is not consumed only through one browser on one device. People may use different browsers, operating systems, screen readers, magnification tools, voice input, or other assistive technologies.

The underlying structure and semantics of a page therefore need to communicate information in ways those technologies can understand.

Robustness is about compatibility. An interface should not work only because one specific combination of browser and device happens to interpret it correctly today.

WCAG organizes accessibility around four principles: perceivable, operable, understandable, and robust.

What are success criteria?

The four principles make WCAG easier to understand, but they are too broad to determine conformance by themselves.

This is where success criteria become important.

The structure can be understood in three layers:

Principles → Guidelines → Success Criteria

Principles provide the broad foundation. Guidelines describe important accessibility goals within each principle. Success criteria define specific outcomes that can be tested.

For example, saying that content should be perceivable gives us a direction, but it does not yet provide enough information to determine whether a particular page passes or fails. Success criteria translate that direction into requirements that can be evaluated against real content.

W3C describes the success criteria as testable statements. For a given piece of content, the goal is to determine with a high level of confidence whether the criterion is satisfied.

The word testable is important, but it does not mean automatically testable.

Some accessibility problems can be detected by software. Others require human judgment. A tool may be able to detect that an image has an alt attribute, for example, but it cannot reliably determine in every situation whether the alternative text communicates the information the image actually provides.

The same applies to many interaction and content questions.

That is why an accessibility evaluation often combines automated testing, manual checks, and testing by people who understand how disabled users interact with the web.

WCAG gives teams a standard against which to evaluate a product. It does not eliminate the need for professional judgment.

WCAG turns broad accessibility principles into specific criteria that teams can evaluate consistently.

A, AA and AAA explained

WCAG success criteria are assigned to three conformance levels: A, AA and AAA.

These levels are frequently misunderstood as a simple quality score, as though A meant poor accessibility, AA meant good accessibility, and AAA meant perfect accessibility.

That is not how the model works.

Level A is the minimum level of conformance. A page conforming at Level A satisfies all applicable Level A success criteria.

Level AA includes both Level A and Level AA criteria.

Level AAA includes Level A, Level AA and Level AAA criteria.

The levels therefore represent cumulative sets of requirements, not grades awarded to the visual or experiential quality of a website.

Many organizations use WCAG 2.2 Level AA as their practical target. This is also why searches and accessibility requirements so often refer to “WCAG AA.”

But Level AA should not be interpreted as “fully accessible,” just as AAA should not be interpreted as “perfect accessibility.”

W3C explicitly notes that Level AAA conformance is not recommended as a general policy for entire sites because some types of content cannot satisfy every Level AAA success criterion.

Teams can also go beyond the minimum requirements of the conformance level they target. A product aiming for AA may still satisfy selected AAA criteria where those requirements are relevant and achievable.

The useful question is not “what is the highest badge we can claim?” It is “which accessibility barriers are we preventing, and what level of conformance are we actually able to demonstrate?”

Why WCAG 2.2 matters

WCAG has evolved as the web and our understanding of digital accessibility have evolved.

WCAG 2.2 became a W3C Recommendation in October 2023 and added nine success criteria compared with WCAG 2.1.

Those additions address areas including focus visibility, alternatives to dragging, minimum target size, consistent access to help, avoiding repeated data entry, and accessible authentication.

The details vary, but several of the additions reflect a broader concern with barriers that appear in modern interaction patterns.

For example, dragging may be simple for someone using a mouse or touchscreen with precise movement, but difficult or impossible for a person who cannot perform that gesture. Authentication processes that depend heavily on memory or cognitive tests can create barriers even when the rest of an interface is accessible. Small targets can make interaction unnecessarily difficult for people with limited dexterity.

WCAG 2.2 does not make earlier versions meaningless. W3C publishes WCAG 2.0, 2.1 and 2.2 as stable standards, and the requirements from earlier versions are largely carried forward.

There is one notable structural change: success criterion 4.1.1 Parsing is obsolete and was removed from WCAG 2.2.

For new accessibility work in 2026, however, WCAG 2.2 is the sensible reference point because it represents the most recent version of WCAG 2 and includes requirements introduced after WCAG 2.1.

Does meeting WCAG mean a website is perfectly accessible?

No.

WCAG conformance is extremely important, but it has a specific meaning.

To conform to WCAG, content needs to satisfy the applicable success criteria at the claimed level together with the other conformance requirements. That gives organizations a clear and consistent standard against which to evaluate a digital product.

But a successful conformance evaluation does not guarantee that every person with every disability will have an excellent experience.

W3C itself recognizes this distinction. Its guidance explains that content can satisfy all success criteria and still not be usable by people with a wide variety of disabilities. It therefore recommends usability testing in addition to functional conformance testing and recommends including people with disabilities in human testing.

This is closely related to the distinction we explored in Accessibility, Usability and User Experience: What’s the Difference?.

A form may satisfy the relevant technical criteria and still contain unnecessarily confusing language. A workflow may support keyboard navigation but demand too much cognitive effort. A navigation structure may be semantically correct while being much more complex than users need.

WCAG helps define an essential accessibility baseline. It should not become a reason to stop asking whether the product actually works well for people.

What about WCAG 3?

WCAG 3 is the next generation of W3C accessibility guidance, but it is important not to treat it as a finished replacement for WCAG 2.2.

On March 3, 2026, W3C published an updated Working Draft of WCAG 3. The draft explores a broader approach to accessibility guidance and a different structure and conformance model from WCAG 2.

But it remains a Working Draft.

That means its contents are still being developed and can change substantially before the standard is complete.

For organizations planning accessibility work in 2026, the practical consequence is straightforward: do not wait for WCAG 3 before improving accessibility.

WCAG 2.2 remains the current standard to work against. W3C's own WCAG 3 introductory guidance points organizations toward meeting WCAG 2.2 while WCAG 3 continues to develop.

WCAG 3 is worth following because it indicates where accessibility standards are heading. It is not yet the framework teams should use as a replacement for WCAG 2.2 conformance.

Where should an organization start?

The first step is not to memorize every success criterion.

It is to understand the structure well enough that the standard stops feeling like an unrelated collection of technical rules.

Begin with the four principles. They provide a useful way to think about barriers across design, content, interaction, and implementation.

Then become familiar with the success criteria relevant to the work your team is doing. W3C's How to Meet WCAG 2: Quick Reference is particularly useful because it allows teams to filter and explore requirements without reading the entire specification from beginning to end.

For an existing website, start by identifying where barriers currently appear. Automated tools can help reveal some issues quickly, but manual testing is essential for areas such as keyboard interaction, focus order, zoom, content quality, and component behavior.

For new work, the better strategy is to prevent problems before they spread. Accessibility requirements can influence color choices, interaction patterns, content structure, reusable components, and acceptance criteria while those decisions are still easy to change. We explored this approach in Why accessibility should be part of web design from day one.

Most importantly, avoid making WCAG the responsibility of one specialist at the end of the project.

Designers need to understand the accessibility implications of visual and interaction decisions. Developers need to understand semantics, keyboard behavior, focus, and compatibility with assistive technologies. Content teams need to think about structure, language, alternatives, and instructions. Product owners need to make accessibility part of what the product is expected to achieve.

WCAG becomes much more useful once teams stop seeing it as a list they need to pass and start using it as a shared framework for finding and preventing barriers.

The standard is technical because accessibility needs requirements that can be evaluated consistently. But the purpose behind those requirements is not technical at all.

It is to make sure that more people can actually use the digital products and services they depend on.