Skip to content

WCAG: Web Content Accessibility Guidelines

If you run a website, app, or digital service, you're probably already required to comply with WCAG — even though it isn't a law itself. The Web Content Accessibility Guidelines (WCAG) are the global standard for digital accessibility, and they've been incorporated into legal frameworks across the EU, UK, US, Canada, and Australia. You don't have a choice about whether to follow them; you only have a choice about whether you comply proactively or reactively after a complaint.

Developed by the W3C's Web Accessibility Initiative, WCAG covers visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. It's the closest thing to a universal accessibility rulebook the world has.

The Four Principles: POUR

WCAG is organised around four core principles — often remembered by the acronym POUR. Every success criterion falls under one of these principles.

Perceivable

Users must be able to perceive the information being presented. It cannot be invisible to all of their senses.

  • Text alternatives — Non-text content must have text alternatives (alt text for images, captions for video, transcripts for audio).
  • Time-based media — Provide alternatives such as captions, audio descriptions, and sign language interpretation for pre-recorded and live media.
  • Adaptable — Content must be structured so it can be presented in different ways without losing information (e.g., simplified layout, larger text, screen reader output).
  • Distinguishable — Make it easier for users to see and hear content, including colour contrast minimums, text resizing, and avoiding sensory characteristics as the sole means of conveying information.

Operable

Users must be able to operate the interface. The interface cannot require interaction that a user cannot perform.

  • Keyboard accessible — All functionality must be operable through a keyboard interface alone.
  • Enough time — Users must have sufficient time to read and use content. Provide mechanisms to adjust, extend, or disable time limits.
  • Seizure prevention — Do not design content in ways that are known to cause seizures. Nothing that flashes more than three times per second.
  • Navigable — Provide ways to help users navigate, find content, and determine where they are. Skip links, descriptive headings, clear focus indicators, and consistent navigation.

Understandable

Users must be able to understand the information and the operation of the interface.

  • Readable — Text content must be readable and understandable. Identify the language of the page and of unusual words or abbreviations.
  • Predictable — Web pages must appear and operate in predictable ways. Consistent navigation, no unexpected context changes on focus or input.
  • Input assistance — Help users avoid and correct mistakes. Descriptive labels, error identification, suggestions for correction, and options to reverse submissions.

Robust

Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies.

  • Compatible — Maximise compatibility with current and future user agents, assistive technologies, and browser tools. Valid HTML, proper ARIA roles, and semantic markup.

Conformance Levels

WCAG defines three levels, and they're not equally useful. Level A removes the most critical barriers — it's the bare minimum. Most legal frameworks target Level AA, which addresses the most common accessibility barriers for most disabilities. Level AAA is the highest but may not be achievable for all content types; it's rarely mandated and considered best-effort.

The practical answer for most organisations: target WCAG 2.2 Level AA. That's what the European Accessibility Act, the UK regulations, and most other legal frameworks reference. Level A alone won't keep you out of trouble, and Level AAA is aspirational for most content.

WCAG 2.1 vs WCAG 2.2

WCAG 2.2 (published October 2023) adds nine new success criteria focused on mobile accessibility and cognitive disabilities. If you're already at WCAG 2.1 AA, the jump isn't enormous, but there are a few that'll require attention.

The biggest operational impact is Target Size (AA) — interactive elements must be at least 24x24 CSS pixels. This affects button and link spacing on mobile interfaces and catches a surprising number of sites off guard. Accessible Authentication (AA) means you can't require users to solve a puzzle or recognise an image to log in — passwords are fine, but CAPTCHAs based on cognitive tasks are not. Dragging Movements (AA) means every drag-and-drop interface must have a click alternative.

Other additions include Focus Not Obscured (AA/AAA), Consistent Help (A), Redundant Entry (A), and Page Break Navigation (A). Most organisations at WCAG 2.1 AA can close the gap to 2.2 with a focused sprint — but the Target Size criterion often requires design system changes.

WCAG isn't a law, but it's embedded in binding legislation across most major economies. The pattern is consistent: governments mandate WCAG 2.1 or 2.2 Level AA, starting with the public sector and expanding to private companies.

In the EU, the European Accessibility Act (2019/882) requires WCAG 2.1 Level AA (via EN 301 549) for products and services placed on the market after June 2025 — including private-sector offerings. The Web Accessibility Directive already applies to public sector sites. The UK mandates WCAG 2.2 AA for public bodies under the 2018 regulations, with the Equality Act covering private sector reasonable adjustments.

In North America, the US enforces Section 508 (federal agencies) and courts have interpreted the ADA to require WCAG 2.1 AA for private businesses. Canada's Accessible Canada Act requires WCAG 2.1 AA for federally regulated organisations, and Ontario's AODA goes further by covering private sector.

Australia, Germany, France, and others follow the same trajectory. The direction of travel is clear: WCAG 2.2 Level AA is becoming the global baseline, and enforcement is moving from the public sector into private industry.

Testing and Validation

Here's what most teams get wrong: they run an automated tool, get a passing score, and declare themselves compliant. Automated testing catches about 25-35% of WCAG success criteria — colour contrast, alt text presence, heading structure, ARIA usage. The other 65-75% requires actual human judgment.

A mature testing programme uses five layers. Automated checks run on every build or deployment. Manual testing — keyboard navigation, focus order, screen reader behaviour, zoom and text resizing — happens per major release. Assistive technology testing with JAWS, NVDA, VoiceOver, or TalkBack covers real-world behaviour. User testing with people who have disabilities should happen quarterly or semiannually. And an expert audit by an accessibility specialist is worth doing annually or before any major redesign.

Accessibility isn't a checklist. It's a user experience question. No tool can tell you whether a screen reader user can actually complete your checkout flow — only a human can.

Preparing for WCAG Compliance

  • Adopt an accessibility policy — Formalise commitment to WCAG conformance with target level and timeline.
  • Build accessibility into design — Include accessibility requirements in design system, component library, and UI kit. Address colour contrast, focus states, and target sizes from the start.
  • Train your team — Developers need to understand semantic HTML, ARIA roles, and keyboard navigation. Designers need to understand colour contrast, focus indicators, and content structure.
  • Write an accessibility statement — Publish a statement explaining your conformance level, known limitations, testing methodology, and contact information for reporting issues.
  • Establish a monitoring process — Automated checks per deployment, manual checks per release, annual expert audit. Publish results in your accessibility statement.

Frequently Asked Questions

Does WCAG compliance apply to mobile apps?

Yes. WCAG success criteria apply to native mobile applications to the same degree as web content. The European Accessibility Act and many national laws explicitly cover mobile applications.

What is the difference between WCAG and EN 301 549?

EN 301 549 is the European standard for ICT accessibility. It incorporates WCAG 2.1 Level AA as its web content requirements and adds criteria for non-web ICT (operating systems, document formats, telecommunications). Compliance with EN 301 549 implies WCAG 2.1 AA compliance for web content.

Can I achieve WCAG compliance with automated testing alone?

No. Automated tools can only detect a subset of success criteria. A 2024 study by the W3C found that automated testing in isolation catches approximately 30% of accessibility barriers. Manual testing and user testing are essential.

Is WCAG compliance retroactive?

Laws differ. The EU Web Accessibility Directive applies to existing content on public sector sites. The European Accessibility Act applies to products and services placed on the market after June 2025. Most litigation under the US ADA focuses on current accessibility barriers rather than historical compliance.

What is the cost of non-compliance?

Beyond legal penalties, non-compliance excludes an estimated 15% of the global population who experience some form of disability. For public-sector organisations, this can mean legal action, remedial orders, and reputational damage. For private companies, it increasingly means lost revenue, ADA lawsuits, and exclusion from public procurement contracts.