WCAG 2.2 Success Criteria Explained in Plain English

WCAG 2.2 success criteria are the testable requirements used to evaluate whether web content and digital interfaces are accessible. They help auditors identify barriers, map findings to recognized standards, explain user impact, and give teams a practical remediation path.

In plain English, a success criterion is a specific accessibility rule that can be checked. For example, users should be able to operate functionality with a keyboard, understand form errors, see enough contrast, receive captions where needed, and use controls that expose correct names, roles, and states to assistive technology.

WCAG 2.2 is organized under four principles: perceivable, operable, understandable, and robust. These are often shortened to POUR. The principles describe the broad outcomes, while guidelines and success criteria break those outcomes into more specific checks.

W3C describes WCAG 2.2 success criteria as testable statements that are not technology-specific. This is important because the same criterion can apply across HTML pages, web apps, components, documents published online, and different device contexts.

WCAG success criteria are assigned conformance levels: A, AA, and AAA. Level A covers foundational barriers. Level AA is the common target for most audits, procurement expectations, and policy requirements. Level AAA is stricter and is often treated as advisory or applied selectively.

For audit buyers, the key decision is usually whether the target is WCAG 2.1 AA or WCAG 2.2 AA. The scope should name the version and level clearly so the report, remediation, and retesting all use the same target.

Perceivable criteria ask whether users can receive the information being presented. If content is only available visually or only through audio, some users may be excluded.

In audits, perceivable findings often involve text alternatives, captions, structure, reading order, colour contrast, text resizing, reflow, and content that appears on hover or focus.

Operable criteria ask whether users can move through the interface and complete actions. This includes people using keyboards, screen readers, switch devices, voice input, touch, or other assistive technology.

In audits, operable issues are often high-impact because they block task completion. A user may be able to read a page but still be unable to submit a form, close a modal, open a menu, use a date picker, or complete payment.

Understandable criteria ask whether users can understand the content, interface behavior, forms, instructions, and error messages. Accessibility is not only about reaching controls; users also need to know what to do.

These criteria are especially important for forms, authentication, checkout, onboarding, KYC, service applications, financial actions, and workflows where errors can block completion.

Robust criteria ask whether content can be interpreted reliably by browsers, assistive technologies, and other user agents. The goal is compatibility, not only visual correctness.

For audits, robust findings often involve accessible names, roles, states, values, status messages, and incorrect use of ARIA. WCAG 2.2 marks Parsing as obsolete and removed, but semantic correctness and assistive technology compatibility remain important through other active criteria.

WCAG 2.2 extends WCAG 2.1. W3C states that content conforming to WCAG 2.2 also conforms to WCAG 2.1 and WCAG 2.0, and that WCAG 2.2 does not deprecate or supersede earlier WCAG 2 recommendations.

For audit readiness, the most visible WCAG 2.2 additions affect focus visibility, dragging, target size, consistent help, redundant entry, and accessible authentication. These issues commonly appear in modern web apps, mobile-responsive flows, account journeys, and complex components.

A useful audit report does not simply list failed criteria. It connects the criterion to the affected user journey, observed barrier, evidence, severity, remediation guidance, and retest result.

This matters because a single WCAG criterion can fail in many different ways. For example, keyboard accessibility can fail in a menu, modal, date picker, upload control, payment form, or embedded widget. The report should explain the specific behavior that needs to change.

The most common mistake is treating WCAG as a checklist detached from user journeys. Success criteria matter because they help identify user barriers, not because they create labels for a report.

Another mistake is assuming automated tools can validate every criterion. Automated checks are useful, but many WCAG criteria require human judgment, manual testing, assistive technology review, and workflow evaluation.

For most organizations, the practical target is not memorizing every WCAG 2.2 success criterion. The practical target is building an audit process that maps barriers clearly, prioritizes issues by user impact, gives teams remediation direction, and verifies closure.

Use WCAG 2.2 success criteria as the standards language. Use manual testing, assistive technology checks, and evidence to prove what is happening in the product. Use retesting to confirm that remediation actually removed the barrier.

W3C WCAG 2.2: https://www.w3.org/TR/WCAG22/

W3C How to Meet WCAG 2.2 Quick Reference: https://www.w3.org/WAI/WCAG22/quickref/

W3C WCAG Overview: https://www.w3.org/WAI/standards-guidelines/wcag/

W3C Evaluating Web Accessibility Overview: https://www.w3.org/WAI/test-evaluate/