WCAG: Web Content Accessibility Guidelines Explained

What is WCAG?

WCAG is a set of guidelines, principles, and testable success criteria designed to make web content accessible to people with disabilities. The standard is developed and maintained by the World Wide Web Consortium (W3C) through the Web Accessibility Initiative (WAI), in an open process involving accessibility researchers, disability advocacy organizations, and representatives from industry and government.

WCAG isn’t just an aspirational standard — it’s the technical reference behind most of the world’s accessibility laws. The US Section 508, the DOJ’s April 2024 Title II Final Rule (with deadlines extended by the April 20, 2026 Interim Final Rule to April 26, 2027 / April 26, 2028), the European EN 301 549 and EAA (enforced since June 28, 2025), Canada’s Accessible Canada Act, the UK’s PSBAR, and dozens of national laws all reference WCAG at a specific version and conformance level. Understanding WCAG is understanding the legal floor for digital accessibility.

WCAG version history

WCAG 1.0 (1999)

Published May 5, 1999, WCAG 1.0 was the first formal web accessibility standard. It contained 14 guidelines organized as a flat list — straightforward but technology-specific. Many of its guidelines referenced HTML elements directly (e.g., specific advice about <table> markup), which made the standard hard to apply to emerging technologies like dynamic web applications, multimedia, and mobile.

WCAG 1.0 used three priority levels (1, 2, 3) corresponding to “must, should, and may” requirements. It became the basis for the original Section 508 standards (1998 amendment) and many early national accessibility laws. WCAG 1.0 was officially superseded by 2.0 but is no longer the operative standard anywhere.

WCAG 2.0 (2008)

Published December 11, 2008, WCAG 2.0 was a substantial restructuring. It moved away from technology-specific guidance toward technology-neutral principles, organizing 12 guidelines under 4 principles — Perceivable, Operable, Understandable, Robust (POUR) — with each guideline supported by testable success criteria at three conformance levels (A, AA, AAA).

WCAG 2.0 became the ISO/IEC 40500:2012 international standard in October 2012, cementing its global status. The 2017 Section 508 refresh (effective January 18, 2018) incorporates WCAG 2.0 Level AA by reference, and many older legal frameworks still cite 2.0 as their normative target.

WCAG 2.1 (2018)

Published June 5, 2018, WCAG 2.1 added 17 new success criteria addressing gaps in 2.0 — particularly around mobile accessibility, low vision, and cognitive disabilities. New criteria included:

• 1.3.4 Orientation — content not restricted to a single screen orientation
• 1.3.5 Identify Input Purpose — autocomplete attributes for common form fields
• 1.4.10 Reflow — content usable at 400% zoom on a 320-pixel viewport without horizontal scrolling
• 1.4.11 Non-text Contrast — 3:1 minimum contrast for UI components and graphics
• 1.4.12 Text Spacing — no loss of content when users override text spacing
• 2.5.x Pointer Gestures, Pointer Cancellation, Label in Name, Motion Actuation, Target Size (AAA) — touchscreen and motor accessibility
• 4.1.3 Status Messages — programmatic notification of dynamic state changes

WCAG 2.1 is the operative standard for the US DOJ’s April 2024 Title II Rule, the European EAA via EN 301 549 v3.2.1, Canada’s ACA, and most state-level US accessibility laws written or revised since 2019.

WCAG 2.2 (2023)

Published October 5, 2023, WCAG 2.2 added 9 new success criteria distributed across the POUR principles, focused on cognitive accessibility, low-vision needs, and authentication:

• 2.4.11 Focus Not Obscured (Minimum) and 2.4.12 Focus Not Obscured (Enhanced) — focused elements not hidden behind sticky headers, cookie banners, or persistent overlays
• 2.4.13 Focus Appearance (AAA) — focus indicators meet specific size and contrast requirements
• 2.5.7 Dragging Movements — drag operations have a single-pointer alternative
• 2.5.8 Target Size (Minimum) — interactive targets at least 24×24 CSS pixels (with limited exceptions)
• 3.2.6 Consistent Help — help mechanisms appear in the same relative position across pages
• 3.3.7 Redundant Entry — previously-entered information must not require re-entry within a session
• 3.3.8 Accessible Authentication (Minimum) and 3.3.9 Accessible Authentication (Enhanced) — login flows can’t require a cognitive test that assistive technology can’t pass

WCAG 2.2 is fully backward-compatible with 2.1 — every 2.1 success criterion remains in 2.2 (with one technical deprecation: 4.1.1 Parsing was removed because modern HTML parsers handle malformed markup gracefully). Targeting 2.2 AA automatically satisfies 2.1 AA. As of 2026, most legal references still cite 2.1, but 2.2 is the forward-looking target.

WCAG 3.0 (in development)

WCAG 3.0 (also called “WCAG-3” or by its earlier name “Silver”) is in active development at the W3C. It represents a substantial restructuring rather than an incremental update:

• Outcome-based conformance model — instead of binary pass/fail success criteria, sites earn a score across multiple outcome categories (Bronze, Silver, Gold).
• Broader content scope — covers technology beyond web (apps, AR/VR, conversational interfaces, AI-generated content).
• More cognitive and learning disabilities focus — long-standing gap in WCAG 2.x coverage.
• Plain-language guideline structure — easier for non-experts to understand and apply.

WCAG 3.0 is not expected to be the operative legal standard anywhere before approximately 2028–2030. For 2026 compliance decisions, WCAG 2.1 or 2.2 AA remains correct. Track WCAG 3.0 progress through the W3C’s WAI working drafts, but don’t refactor your accessibility program around it yet.

The 4 principles of accessibility (POUR)

WCAG 2.x organizes all guidelines under four foundational principles, summarized as POUR. See our dedicated POUR website guide for detailed implementation guidance per principle.

1. Perceivable

Users must be able to perceive the information and interface via sight, sound, or touch. Practical implementations: alt text for non-text content, captions and transcripts for time-based media, adaptable content layouts, sufficient color contrast (4.5:1 normal text, 3:1 non-text UI per WCAG 2.x).

2. Operable

Users must be able to operate the interface. Practical implementations: full keyboard accessibility, no keyboard traps, adjustable timeouts, no seizure-triggering content, navigable structure with skip links and visible focus, target size and consistent help (WCAG 2.2 additions).

3. Understandable

Information and interface must be understandable. Practical implementations: readable language with declared lang attribute, predictable behavior, clear error messages, accessible authentication flows that don’t require cognitive tests assistive technology can’t pass (WCAG 2.2 addition).

4. Robust

Content must be robust enough to work with current and future assistive technologies. Practical implementations: semantic HTML, correctly used ARIA, valid markup that parses cleanly, programmatic notification of dynamic state changes (WCAG 2.1 addition).

WCAG conformance levels

WCAG 2.x organizes success criteria into three conformance levels, layered cumulatively — meeting Level AA requires also meeting all Level A criteria, and meeting Level AAA requires meeting all Level A and AA criteria.

Level A — minimum conformance

The most fundamental success criteria. Failing a Level A criterion typically means the content is unusable for some users with disabilities. Examples: keyboard accessibility (2.1.1), text alternatives for images (1.1.1), captions for pre-recorded video (1.2.2), no seizure-triggering content (2.3.1), language identified (3.1.1), name/role/value exposed to assistive tech (4.1.2).

Level A alone is generally insufficient for legal compliance. It’s the floor below which content is broadly inaccessible.

Level AA — standard conformance target

Includes everything in Level A, plus additional criteria around contrast (4.5:1 text, 3:1 non-text), reflow at 400% zoom, identifying input purpose, focus visible, descriptive page titles and headings, navigable site structure. Level AA is the standard conformance target for virtually every major accessibility law:

• US DOJ Title II Rule (April 2024) → WCAG 2.1 AA
• Section 508 (2017 refresh) → WCAG 2.0 AA
• EU EAA / EN 301 549 → WCAG 2.1 AA
• Canada ACA / CAN/ASC-EN 301 549 → WCAG 2.1 AA
• UK PSBAR → WCAG 2.1 AA
• Australia (federal procurement, public-sector sites) → WCAG 2.1 AA

Targeting WCAG 2.2 Level AA satisfies all current legal requirements while positioning the organization for forthcoming regulatory updates that reference 2.2.

Level AAA — enhanced conformance

Includes everything in Levels A and AA, plus more rigorous criteria: 7:1 contrast (vs. 4.5:1), sign language interpretation for video, audio descriptions for all video, no images of text except logos, contextual help available throughout, more comprehensive reading-level requirements.

WCAG explicitly notes that Level AAA conformance is not achievable for some content categories (live captions in real-time, sign language for all video). It’s an aspirational target rather than a universal compliance baseline. Most regulated organizations target AA universally and add AAA criteria selectively where their user base needs them — for example, sites serving users with low vision specifically might target the 7:1 contrast ratio.

How to evaluate WCAG conformance

Conformance evaluation is a layered process. Automated tools catch a portion of issues; the rest requires human review.

Automated testing

Tools like axe DevTools (browser extension), WAVE (WebAIM), Lighthouse (built into Chrome DevTools), and Pa11y (CLI for CI integration) scan pages against WCAG success criteria and surface violations. Free tools cover most of the automated-detectable rules; paid tools (Deque axe Auditor, Siteimprove, Tenon, Monsido) add scale, monitoring, and enterprise reporting. Industry research consistently finds that automated tools detect 30–50% of WCAG issues; the rest require human review.

Manual testing

Manual testing catches the issues automated tools miss. The high-impact tests:

• Keyboard-only navigation — unplug the mouse, navigate with Tab, Shift+Tab, Enter, Space, Arrow keys, Esc.
• Screen reader testing — NVDA (free, Windows), VoiceOver (built-in, macOS/iOS), TalkBack (Android). Twenty minutes on critical workflows reveals issues automated tools miss.
• Zoom testing — 200% (WCAG 1.4.4) and 400% (WCAG 1.4.10 Reflow).
• Forced Colors Mode — Windows 11 Contrast themes or DevTools emulation surface color-dependent UI that breaks under user overrides.
• User testing with people who have disabilities — gold-standard validation; services like Fable, Applause, and UserTesting accessibility panels provide structured access.

See our manual accessibility testing guide for detailed methods.

Conformance reporting

For organizations producing accessibility documentation (procurement responses, regulated industry compliance, legal defense), the standard format is the Accessibility Conformance Report (ACR), also known as the VPAT (Voluntary Product Accessibility Template). Current version: VPAT 2.5 (published 2024 by ITI), with editions for Section 508, WCAG 2.x, EN 301 549, and an “international” version covering all three. ACRs document the conformance level of specific software products and are increasingly required as part of vendor procurement processes.

What WCAG doesn’t cover

WCAG is necessary but not sufficient. Several accessibility concerns sit outside its scope:

• Native mobile applications — WCAG applies to web technologies (HTML, CSS, JavaScript, ARIA). For native iOS and Android apps, equivalents like Apple’s Accessibility Programming Guide for iOS and Google’s Android Accessibility documentation apply, supplemented by EN 301 549 for European compliance and the IAAP’s Accessible Document Specialist (ADS) certification for native document formats.
• Hardware and physical interfaces — covered by EN 301 549 and Section 508 directly, not WCAG.
• Service quality and human assistance — accessible self-service is a WCAG concern; accessible customer service is not.
• Some cognitive disability needs — historically under-served by WCAG 2.x; expanded coverage is a major focus of WCAG 3.0.
• AI-generated and AI-mediated content — emerging area; WCAG 3.0 explicitly aims to address conversational interfaces, generated content, and AI-mediated experiences.

How WCAG fits into the broader accessibility landscape

Other relevant standards and frameworks complement WCAG:

• EN 301 549 — European harmonized standard for ICT accessibility, currently v3.2.1 (2021). References WCAG 2.1 AA for web content; adds requirements for hardware, software applications, documentation, and support services that WCAG doesn’t cover. Adopted or mirrored by many non-EU countries (Canada’s CAN/ASC-EN 301 549, Australia’s AS EN 301 549).
• Section 508 — US federal accessibility law referencing WCAG 2.0 AA since the 2017 refresh.
• ATAG (Authoring Tool Accessibility Guidelines) — W3C standard for tools that produce web content (CMSs, document editors, etc.). Currently ATAG 2.0.
• UAAG (User Agent Accessibility Guidelines) — for browsers and assistive technology platforms. Less actively maintained than WCAG and ATAG.
• WAI-ARIA — Accessible Rich Internet Applications specification. Defines roles, states, and properties that expose UI semantics to assistive technologies. Currently WAI-ARIA 1.2.

Frequently asked questions

Which WCAG version should I target in 2026?

WCAG 2.2 Level AA is the right target. It’s backward-compatible with 2.1 (which is referenced by most current laws), satisfies legal requirements for state and local government sites under the DOJ Title II Rule, and positions the organization for forthcoming regulatory updates that reference 2.2.

Are WCAG 1.0 and Section 508 (1998) still valid targets?

No. WCAG 1.0 was officially superseded by 2.0 in 2008 and is no longer the operative standard anywhere. The original 1998 Section 508 standards were replaced by the 2017 refresh (effective January 18, 2018), which references WCAG 2.0 AA. Sites still claiming “Section 508 compliance” against the 1998 baseline are technically out of compliance even with current Section 508 requirements.

Does WCAG cover mobile apps?

Indirectly. WCAG applies to web technologies; for native iOS and Android apps, platform-specific accessibility APIs (Apple Accessibility, Android Accessibility) apply. EN 301 549 (referenced by the EAA) explicitly covers mobile applications and includes WCAG-aligned requirements. In practice, native apps targeting WCAG 2.2 AA principles cover most of what’s needed.

What’s the relationship between WCAG and ARIA?

ARIA (Accessible Rich Internet Applications) is a separate W3C specification that defines roles, states, and properties for exposing UI semantics to assistive technology. WCAG references ARIA where appropriate (notably in 4.1.2 Name, Role, Value), but ARIA is its own technical standard. Use ARIA when native HTML doesn’t carry the semantics you need — and use it correctly, since incorrect ARIA is worse than no ARIA. The W3C’s First Rule of ARIA: don’t use ARIA when a native HTML element exists for the job.

How often does WCAG update?

Major versions arrive every several years (2.0 in 2008, 2.1 in 2018, 2.2 in 2023). Within a major version, the W3C publishes errata and clarifying updates more frequently. For practical purposes, plan to revisit your conformance target every 3–5 years as new versions become referenced by laws.

Should I wait for WCAG 3.0 before doing major accessibility work?

No. WCAG 3.0 is years from being the operative legal standard, and a major restructuring will require organizations to reassess their conformance approach when it does become operative. For 2026, building to WCAG 2.2 AA is correct, and that work will not be wasted — the underlying accessibility outcomes (perceivable, operable, understandable, robust content) are stable across versions.

Bottom line

WCAG is the international standard for web accessibility, the technical reference behind virtually every accessibility law in the world, and the foundation of any organizational accessibility program. The version that matters in 2026 is WCAG 2.2 Level AA — backward-compatible with 2.1 (the most-referenced legal target), forward-positioned for regulatory updates that adopt 2.2, and grounded in the same POUR principles that have organized the standard since 2008. Target AA universally, layer in AAA selectively where users need it, evaluate conformance with both automated and manual methods, and document with a current ACR. WCAG 3.0 will eventually replace the 2.x series, but not before 2028–2030 at earliest. For now, 2.2 AA is the answer.