WCAG: Web Content Accessibility Guidelines Explained

What are the Web Content Accessibility Guidelines (WCAG)?

The Web Content Accessibility Guidelines (WCAG) are the W3C's technical standard for making web content usable by people with disabilities. They are organised into four principles, testable success criteria and three conformance levels (A, AA, AAA). The current version is WCAG 2.2, and most accessibility rules and procurement checklists point to it.

WCAG is written by the W3C's Accessibility Guidelines Working Group as part of the Web Accessibility Initiative. It covers websites and web apps, and it applies to the content users get, not to a particular framework or tool.

The four principles: POUR

Every success criterion sits under one of four principles, known as POUR:

• Perceivable: information must be presentable in ways users can perceive, for example text alternatives for images, captions for video and enough colour contrast.
• Operable: every function works with a keyboard, users get enough time, nothing triggers seizures, and navigation is clear.
• Understandable: text is readable, pages behave predictably and forms help users avoid and fix mistakes.
• Robust: content works with current and future browsers and assistive technology, so names, roles and values are exposed correctly.

Conformance levels A, AA and AAA

• Level A is the minimum: images have text alternatives, video has captions, everything can be reached by keyboard.
• Level AA is the usual target. It includes 4.5:1 contrast for normal text (3:1 for large text), 3:1 contrast for UI components and graphics, and, new in 2.2, pointer targets of at least 24 by 24 CSS pixels (or enough spacing around smaller ones).
• Level AAA adds stricter criteria. The W3C does not recommend requiring it for whole sites, because some criteria cannot be met for all content.

Conformance is judged per page, and a page only conforms to a level if it meets every criterion of that level and the ones below it.

WCAG versions: 2.0, 2.1, 2.2 and 3.0

• WCAG 2.0 was published in December 2008.
• WCAG 2.1 (June 2018) added 17 success criteria, mostly for mobile, low vision and cognitive needs.
• WCAG 2.2 is a W3C Recommendation (updated December 2024). It adds 9 success criteria, among them Focus Not Obscured, Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry and Accessible Authentication, and it removes 4.1.1 Parsing as obsolete.
• WCAG 3.0 is still a Working Draft (10 September 2026 at the time of writing). The W3C says it does not replace WCAG 2, so teams should keep targeting 2.2.

The W3C designed 2.0, 2.1 and 2.2 to be backward compatible: content that meets 2.2 also meets 2.1 and 2.0. Read the full text in the WCAG 2.2 Recommendation.

A practical example

A "Buy now" button uses light grey text (#999999) on a white background. The contrast ratio is about 2.8:1, so it fails 1.4.3 (Contrast Minimum) at Level AA, even though it looks fine on a bright monitor. Switching the text to #767676 gives about 4.5:1 and passes. The same button also needs a visible focus indicator, a target at least 24 by 24 CSS pixels and an accessible name that matches its visible label.

What fails most often

The WebAIM Million 2026 analysis of one million home pages found detectable WCAG 2 failures on 95.9% of them. The most common were low-contrast text (83.9% of pages), missing image alt text (53.1%), missing form labels (51%), empty links (46.3%), empty buttons (30.6%) and a missing document language (13.5%). These are cheap to fix, so they are a good first sprint.

Common mistakes

• Treating accessibility as a last-step checklist. It costs far less to build contrast, focus states and semantic HTML into the design system from the start.
• Relying on automated scans alone. Automated testing catches only what a rule can detect, such as missing alt attributes. It cannot judge whether alt text is meaningful or whether the reading order makes sense, so add manual tests with a keyboard and a screen reader.
• Using ARIA instead of native HTML. A real <button> brings keyboard and screen reader support for free. A <div role="button"> needs all of it rebuilt.
• Confusing a report with conformance. A VPAT or an Accessibility Conformance Report only documents what you tested. It does not make a page accessible.

WCAG and your testing routine

Run WCAG checks alongside performance checks, since both are regressions you want to catch before users do. LoadFocus Page Speed Monitoring runs scheduled Google Lighthouse audits from 25 cloud regions, and each audit includes the Lighthouse Accessibility category. That gives you a trend line for the automated part of WCAG. It is not a full accessibility audit and does not replace manual testing. For the wider argument, read why performance testing should include accessibility metrics.

FAQ: WCAG

Is WCAG legally required?

Often indirectly. Laws such as the EU Web Accessibility Directive (public sector) refer to WCAG through the EN 301 549 standard, and the European Accessibility Act, which applies from 28 June 2025, covers services such as e-commerce and banking. Which WCAG version and level a rule cites differs by country and sector, so check the rule that applies to you.

Which WCAG version should I target?

WCAG 2.2 Level AA. It is the current Recommendation, and because it is backward compatible, meeting it also meets 2.1 and 2.0. WCAG 3.0 is a draft and does not replace WCAG 2.

What is the difference between A, AA and AAA?

They are cumulative levels of strictness. A is the minimum, AA adds criteria such as 4.5:1 text contrast and is the common legal and contractual target, and AAA is the strictest and is usually applied to selected content only.

Can an automated tool tell me my site is WCAG compliant?

No. Tools such as Lighthouse check the rules that can be detected in code. Meaningful alt text, logical focus order and clear error messages need a person with a keyboard and a screen reader.

What changed in WCAG 2.2?

Nine success criteria were added, including a 24 by 24 pixel minimum target size, a rule that focused elements are not hidden by sticky headers, alternatives to dragging, and accessible authentication. The obsolete 4.1.1 Parsing criterion was removed.