WCAG Basics

What WCAG is designed to organize

WCAG is developed through the World Wide Web Consortium's accessibility work and is used internationally as a technical framework for web accessibility. The current WCAG 2 family is organized in layers. At the highest layer are four principles, commonly abbreviated POUR: Perceivable, Operable, Understandable, and Robust. A person needs information and interface components to be available to their senses or assistive technology (perceivable); controls must be usable through available methods such as a keyboard (operable); content and operation must make sense (understandable); and the content must work reliably with user agents and assistive technologies as technologies change (robust).

These principles are deliberately broad. They help a team reason about a problem, but they are not individual pass/fail tests. For example, replacing an image with useful text may address a perceivable-information question, while a visible focus indicator concerns operation. A clear error message can support understanding. Valid, semantic markup can contribute to robust interpretation by different tools. One design decision can matter to more than one principle, and one principle contains many more specific requirements. WCAG therefore should not be reduced to a collection of isolated attributes or a screen-reader-only checklist.

From principles to testable requirements

Below the principles, WCAG 2 presents guidelines that state goals, then success criteria that are written to be testable. A success criterion is the level at which conformance is evaluated. Techniques and failures can help people understand ways to meet or fail a criterion, but they are informative guidance rather than the conformance requirements themselves. This distinction matters during a review: a tool may suggest a particular coding technique, yet the team should still identify the relevant success criterion and inspect whether the finished experience meets it.

The success criteria have three conformance levels: A, AA, and AAA. Level A is the baseline set of requirements; AA includes A plus additional requirements; AAA includes A and AA plus further requirements. That structure does not mean that an interface with a few AAA features has "earned AAA." A conformance claim needs to state the evaluated scope, the version of WCAG, and the conformance level, and it depends on meeting all applicable success criteria at that level for the complete process or page scope. WCAG also describes complete processes: if users must complete several steps to accomplish a task, accessibility must be considered across those steps rather than at a single attractive screen.

WCAG 2.2 extends the WCAG 2 series and is backward compatible with earlier WCAG 2 versions, according to W3C. A project should name the version and target it actually uses rather than casually saying "WCAG compliant." Contract terms, institutional policies, and laws can specify a version and level; interpreting those requirements is a legal or policy matter outside this lesson.

Using POUR without turning it into a survey

A productive early review uses POUR to form narrow questions about a user task. Suppose a site adds a "Save changes" control. Perceivable asks whether users can find out what the control is and what happened after activation. Operable asks whether it can be reached and activated with the supported input methods. Understandable asks whether its label and result are clear. Robust asks whether the control's semantics and state can be exposed consistently to user agents and assistive technology. Those questions guide design and testing; they do not substitute for checking applicable success criteria.

This approach also prevents a common mistake: treating WCAG as an implementation recipe. WCAG says what outcomes success criteria require, while a particular HTML element, ARIA pattern, test tool, or design system component is a possible means of achieving an outcome in context. Native semantic HTML is often a sound starting point, but no single markup choice proves that labels, instructions, focus behavior, errors, contrast, and task flow are all usable. Automated checks can locate some issues efficiently; human testing and careful review remain necessary for many questions about meaning, sequence, and interaction.

For a class project, record the scope of what you reviewed, the WCAG version and target level, the relevant success criteria, the evidence you observed, and the remaining uncertainty. That makes the work falsifiable and useful to the next person. It is more responsible than declaring an entire site accessible after checking one page or one tool result.