What are WCAG (Web Content Accessibility Guidelines)?

What are the Web Content Accessibility Guidelines (WCAG)?

The Web Content Accessibility Guidelines (WCAG) are the international standard for digital accessibility, published by the W3C through the Web Accessibility Initiative (WAI). WCAG defines how websites, web applications, and digital documents must be designed and built so that people with disabilities can perceive, operate, understand, and navigate them.

WCAG isn't just guidance — it's the technical foundation referenced by accessibility laws worldwide. The European Accessibility Act, the Americans with Disabilities Act (ADA) court cases, Section 508 of the U.S. Rehabilitation Act, the EU Web Accessibility Directive, the UK Equality Act, Canada's ACA, and Australia's DDA all defer to WCAG as the de facto definition of "accessible."

The four POUR principles

WCAG is structured around four foundational principles, captured in the acronym POUR:

• Perceivable — Users must be able to perceive the content through their available senses. This means text alternatives for images, captions for video, sufficient color contrast, and content that can be presented in different ways without losing meaning.
• Operable — Users must be able to operate the interface. Functionality must be available via keyboard, content must not cause seizures (no flashing more than 3 times per second), users must have enough time to read, and navigation must be predictable.
• Understandable — Users must understand both the content and the operation of the interface. Text must be readable, content must appear and operate in predictable ways, and users must be helped to avoid and correct mistakes.
• Robust — Content must be robust enough to work with current and future user agents, including assistive technologies. Code must be valid, ARIA must be used correctly, and components must communicate their name, role, and value to assistive tech.

The three conformance levels

WCAG defines three levels of conformance, expressing increasing accessibility:

Level A — minimum (the floor)

The most basic requirements. Failing Level A means content is unusable for some groups of disabled users. Examples: every <img> needs alt text, video needs captions, keyboard navigation must work. No site should ever ship without Level A compliance.

Level AA — the legal/practical target

Most accessibility laws and regulations require Level AA. Adds nuanced criteria: 4.5:1 contrast ratio for normal text, captions for live video, focus indicators visible, target sizes meet minimums (24×24 in WCAG 2.2). Level AA is the practical target for production sites.

Level AAA — the enhanced standard

The highest level, often impractical for entire sites because some criteria require radical reorganization. AAA requires: 7:1 contrast, sign language interpretation for video, no time limits anywhere, plain-language reading at lower-secondary level. Most sites target AAA only for specific high-stakes flows (sign-up, checkout, government forms) rather than site-wide.

WCAG version timeline

• WCAG 1.0 (1999) — Original, now obsolete.
• WCAG 2.0 (2008) — Introduced the POUR principles. Still legally valid in many jurisdictions.
• WCAG 2.1 (2018) — Added 17 success criteria for mobile, low vision, and cognitive disabilities. The most-cited version in current law.
• WCAG 2.2 (October 2023) — Adds 9 success criteria for cognitive accessibility, mobile, and low-vision users. Notable additions: target size minimum (Level AA, 24×24px), focus appearance enhanced, accessible authentication, dragging movements alternative.
• WCAG 3.0 (in development) — A complete restructure rather than an incremental update. Uses outcome-based scoring rather than pass/fail criteria. Not yet stable; production teams should still target WCAG 2.2.

The 13 most-failed WCAG criteria (by frequency)

Per the WebAIM Million 2024 report, these criteria fail on the most home pages:

1. 1.4.3 Contrast (Minimum) — 81% of pages have low-contrast text. The single largest accessibility issue on the web.
2. 1.1.1 Non-text Content — 54% of pages have images missing alt text.
3. 4.1.2 Name, Role, Value — 44% of pages have form inputs without proper labels or buttons without accessible names.
4. 2.4.4 Link Purpose — 45% of pages have ambiguous link text ("click here", "read more").
5. 1.3.1 Info and Relationships — 30% have improper heading structure or unlabeled form fields.
6. 3.1.1 Language of Page — 17% missing the lang attribute on <html>.
7. 4.1.1 Parsing — duplicate IDs, unclosed tags, etc. (Note: removed in WCAG 2.2.)
8. 2.4.6 Headings and Labels — Headings that don't describe their topic.
9. 1.4.5 Images of Text — Text rendered as an image instead of selectable text.
10. 2.4.7 Focus Visible — Custom CSS hides the focus ring without replacing it.
11. 3.3.2 Labels or Instructions — Form fields without labels or with placeholder-as-label antipattern.
12. 1.4.4 Resize Text — Layout breaks when text is zoomed.
13. 2.5.3 Label in Name — Visible label text doesn't match accessible name.

Fixing just these 13 issues addresses 95%+ of accessibility complaints on most sites.

WCAG conformance evidence: VPAT, ACR, accessibility audits

Documenting your WCAG compliance is increasingly required by enterprise procurement teams, government RFPs, and accessibility lawsuits. The standard documentation flow:

• VPAT — the empty template provided by the ITI. You fill it in for your product.
• ACR (Accessibility Conformance Report) — the completed VPAT. "We have an ACR" means "we filled in a VPAT."
• Third-party audit — a certified accessibility consultant tests your product manually + with assistive tech and produces a remediation report.
• Annual re-audit — most enterprise procurement requires VPATs/audits to be no older than 12 months.

Common WCAG implementation mistakes

• Treating accessibility as a final-step checklist. WCAG is most expensive when bolted on at the end. Bake it into design (color systems, focus states), components (semantic HTML, proper labels), and CI (axe-core, Pa11y, Lighthouse).
• Relying solely on automated testing. Automated tools catch 30-40% of WCAG violations. The other 60-70% (meaningful alt text, logical tab order, screen reader experience) require manual testing with real assistive tech.
• Confusing legal compliance with usable accessibility. Passing automated checks isn't the same as being accessible. Test with screen readers (NVDA, JAWS, VoiceOver), keyboard-only navigation, and ideally users with disabilities.
• Aria where semantic HTML works. The first rule of ARIA: don't use ARIA. Native <button>, <label>, and <nav> beat custom role="button" on <div> 100% of the time.
• Ignoring cognitive accessibility. WCAG 2.2 added cognitive criteria for a reason. Plain language, predictable patterns, and helpful error recovery aren't optional.
• Mocking the contrast checker. 4.5:1 isn't excessive — it's the floor for users with mild visual impairment. "It looks fine to me" isn't a contrast test.

FAQ: WCAG

Is WCAG legally required?

In many jurisdictions, yes. The European Accessibility Act (effective June 2025) requires WCAG 2.1 AA. The ADA in the U.S. has been interpreted by federal courts to require WCAG conformance. Section 508 of the Rehabilitation Act mandates WCAG 2.0 AA for U.S. federal agencies. Check local law for specific obligations.

What WCAG version should I target in 2026?

WCAG 2.2 Level AA is the current best target. It's the latest stable version with broad regulatory adoption. WCAG 3.0 is still in development; most teams shouldn't target it yet.

How do I know if my site meets WCAG?

Three layers: (1) automated tools (axe DevTools, WAVE, Lighthouse) catch the easy violations; (2) manual testing with keyboard and screen readers catches operational issues; (3) third-party audit catches everything else and produces an ACR.

How much does WCAG compliance cost?

Highly variable. A simple marketing site might be brought to AA for $5K-$15K of design + dev time. A large web application could need $50K-$500K of remediation. Building accessibility in from the start adds ~10-15% to development costs; bolting it on later adds 200-400%.

What's the difference between WCAG and ADA?

WCAG is the technical standard. ADA is U.S. law (Americans with Disabilities Act). U.S. courts have repeatedly held that public-accommodation websites must be accessible, and they use WCAG as the technical definition of "accessible." Other countries' laws cite WCAG similarly.

Does WCAG cover mobile apps?

WCAG was designed for web content but is widely applied to mobile apps too. WCAG 2.1 added mobile-specific criteria (orientation, motion actuation, target sizes), and WCAG 2.2 went further. Native iOS/Android apps also have platform-specific guidelines (Apple Accessibility, Google Accessibility) that complement WCAG.

How LoadFocus fits into accessibility testing

Accessibility goes hand-in-hand with performance — slow pages disproportionately impact users with disabilities (older devices, assistive tech with overhead). LoadFocus website speed testing validates that your accessible site also loads quickly across devices. Synthetic monitoring catches accessibility regressions when you ship — including dropped alt text, broken focus states, and contrast failures introduced by CSS changes.