WCAG Success Criteria

WCAG Success Criteria form the backbone of the Web Content Accessibility Guidelines, a set of internationally recognized standards published by the W3C's Web Accessibility Initiative (WAI). Rather than offering vague recommendations, the guidelines break down into discrete, testable statements—each one a Success Criterion—that specify exactly what web content must do to be considered accessible. WCAG 2.1, for example, contains 78 Success Criteria organized under four principles: Perceivable, Operable, Understandable, and Robust (often abbreviated as POUR).

Each Success Criterion is numbered using a three-part scheme like 1.1.1 (guideline.sub-guideline.criterion) and assigned one of three conformance levels: A (the minimum baseline), AA (the level most laws and policies require), or AAA (the highest, most stringent level). To claim conformance at a given level, a page must satisfy every criterion at that level and all levels below it. For instance, claiming AA conformance means meeting all A and AA criteria.

Why WCAG Success Criteria matter

WCAG Success Criteria matter because they translate the broad goal of "making the web accessible" into concrete, actionable checkpoints. Without them, developers and designers would have no shared standard for measuring whether a site works for people who use screen readers, keyboard-only navigation, switch devices, magnification software, or other assistive technologies.

Legal and policy impact

Many countries—including the United States (Section 508, ADA), the European Union (EN 301 549), Canada, and Australia—reference WCAG 2.x AA conformance in their accessibility laws. Failing to meet Success Criteria can expose organizations to legal risk, fines, and lawsuits.

Who is affected

Every Success Criterion addresses a real-world barrier experienced by real users. Criterion 1.4.3 (Contrast Minimum) helps people with low vision. Criterion 2.1.1 (Keyboard) ensures users who cannot operate a mouse can still navigate. Criterion 1.1.1 (Non-text Content) ensures blind users receive text alternatives for images. When criteria go unmet, entire groups of people are locked out of content and services.

Automated and manual testing

Success Criteria are designed to be testable, which makes them ideal targets for accessibility audits. Some criteria—like color contrast ratios—can be verified automatically by tools such as Rocket Validator. Others—like whether alternative text is meaningful—require human judgment. A robust testing strategy combines both.

How WCAG Success Criteria work

The four principles

Success Criteria are grouped under four principles:

• Perceivable – Information must be presentable in ways all users can perceive (e.g., text alternatives, captions, sufficient contrast).
• Operable – Interface components must be operable by all users (e.g., keyboard accessibility, enough time, no seizure-inducing content).
• Understandable – Content and UI behavior must be understandable (e.g., readable text, predictable navigation, error identification).
• Robust – Content must be robust enough to work reliably with current and future assistive technologies (e.g., valid markup, proper ARIA usage).

Conformance levels

Techniques and failures

The W3C publishes Sufficient Techniques (ways to pass a criterion) and Common Failures (patterns that always fail a criterion). Developers can choose any technique that satisfies the criterion; the techniques are advisory, but the criteria themselves are normative.

Code examples

Below are examples tied to specific Success Criteria, showing common mistakes and their fixes.

SC 1.1.1 – Non-text Content (Level A)

Bad example – An image with no text alternative:

<img src="chart-q3-revenue.png">

A screen reader cannot convey the image's meaning, failing 1.1.1.

Good example – A descriptive alt attribute provides a text alternative:

<img src="chart-q3-revenue.png" alt="Bar chart showing Q3 revenue increased 15% compared to Q2">

SC 1.4.3 – Contrast Minimum (Level AA)

Bad example – Light gray text on a white background (contrast ratio ~1.9:1):

<p style="color: #cccccc; background-color: #ffffff;">
  Important notice about your account.
</p>

This fails the 4.5:1 ratio required for normal text at Level AA.

Good example – Dark text on a white background (contrast ratio ~12.6:1):

<p style="color: #333333; background-color: #ffffff;">
  Important notice about your account.
</p>

SC 2.1.1 – Keyboard (Level A)

Bad example – A div used as a button with only a click handler; unreachable by keyboard:

<div class="btn" onclick="submitForm()">Submit</div>

Good example – A native <button> element that is focusable and operable via keyboard by default:

<button type="button" onclick="submitForm()">Submit</button>

If a non-interactive element must be used, add tabindex="0", a role, and keyboard event handlers:

<div class="btn" role="button" tabindex="0" onclick="submitForm()" onkeydown="if(event.key==='Enter'||event.key===' ')submitForm()">
  Submit
</div>

SC 4.1.2 – Name, Role, Value (Level A)

Bad example – A custom toggle with no accessible name or state:

<span class="toggle" onclick="toggleDarkMode()"></span>

Good example – ARIA attributes expose the name, role, and current state:

<button type="button" role="switch" aria-checked="false" aria-label="Dark mode" onclick="toggleDarkMode(this)">
  Dark mode
</button>

Meeting WCAG Success Criteria is not a one-time task—it requires ongoing attention during design, development, content authoring, and testing. Automated scanners catch many A and AA violations quickly, while manual audits fill in the gaps for criteria that depend on context and meaning. Together, the criteria provide a clear, shared language for building a web that works for everyone.