WCAG Standards and Levels A, AA, AAA

9 min read

Before you can test for accessibility, you need to know what you are testing against. WCAG — the Web Content Accessibility Guidelines — is the international standard that defines what an accessible web experience means. It is the reference every accessibility law points to, every accessibility audit is measured against, and every accessibility requirement in a test plan should cite. This lesson gives you the mental model you need to work with it.

What WCAG is and who maintains it

WCAG is published by the W3C (World Wide Web Consortium) as part of its Web Accessibility Initiative (WAI). It defines technical requirements for making web content accessible to people with disabilities — visual, auditory, motor, and cognitive. The current versions are WCAG 2.1 (2018) and WCAG 2.2 (2023, adding nine new criteria). Most legal requirements and existing test plans reference 2.1; 2.2 is backward-compatible and is where new work should be targeted.

WCAG is organised as a hierarchy: principles contain guidelines, which contain success criteria. Each success criterion is testable — it has an unambiguous pass/fail result.

Three conformance levels: A, AA, AAA

Every WCAG success criterion is assigned to one of three levels:

Level A — the minimum. Failing Level A criteria creates severe barriers for some users — content is unusable for entire groups. Examples: every image must have a text alternative (1.1.1); all functionality must be operable via keyboard (2.1.1); the page must not trigger seizures (2.3.1).

Level AA — the standard target. Level AA adds requirements that significantly improve accessibility without being impractical to implement. This is the level referenced by accessibility laws globally. Examples: text must have a 4.5:1 contrast ratio with its background (1.4.3); keyboard focus must be visible (2.4.7); error messages must identify the field and describe how to fix it (3.3.3).

Level AAA — the enhanced tier. Level AAA includes requirements that are inappropriate or impractical as universal requirements — for example, no time limits on any content (2.2.3), a 7:1 contrast ratio (1.4.6), and sign language interpretation for all video (1.2.6). W3C explicitly states that AAA conformance across an entire site is not recommended as a universal goal. It is appropriate for specific high-stakes flows.

Which level you should target

For the vast majority of products, the answer is WCAG 2.1 Level AA. This is the level mandated by:

  • US ADA (Americans with Disabilities Act) — case law and DOJ guidance consistently reference WCAG 2.1 AA
  • EU EN 301 549 — harmonised European standard for ICT accessibility, referencing WCAG 2.1 AA
  • EU European Accessibility Act (EAA) — enforcement from June 2025, applies to private-sector digital products
  • UK Equality Act 2010 — digital accessibility obligations reference WCAG AA
  • US Section 508 — federal procurement standard (government contractors)

If your product is in healthcare, education, or government, check jurisdiction-specific requirements — some specify WCAG 2.2. If you serve the EU market in any commercial capacity after June 2025, EAA compliance is a legal obligation.

The four POUR principles

WCAG 2.1 / 2.2
  • – Alt text on images (A)
  • – Captions on video (A)
  • – Contrast 4.5:1 (AA)
  • – No info from colour alone (A)
  • – Full keyboard access (A)
  • – Focus visible (AA)
  • – Skip navigation link (A)
  • – No seizure triggers (A)
  • – Form labels (A)
  • – Error messages (AA)
  • – Consistent navigation (AA)
  • – Language declared (A)
  • Valid HTML structure (A) –
  • Name / role / value (A) –
  • Status messages (AA) –

Every WCAG success criterion maps to one of four principles:

Perceivable — users must be able to sense the content. If it is visual, there must be a non-visual alternative. If it is audio, there must be a text alternative. This principle governs alt text, captions, contrast, and not relying on colour alone to convey meaning.

Operable — users must be able to interact with the interface using the tools available to them. All functionality must be keyboard-accessible. No content should trigger seizures. Users need enough time to read and use content. This principle governs keyboard access, focus visibility, timing, and navigation.

Understandable — content and interface behaviour must be comprehensible. Labels must be clear. Error messages must explain both the problem and the fix. Navigation must be consistent across pages. This principle governs form design, error handling, and predictability.

Robust — content must work across current and future assistive technologies. This principle governs semantic HTML, ARIA usage, and ensuring that programmatic structure (name, role, value) is correctly exposed to assistive technology APIs.

How to specify WCAG in test plans

When writing a test plan or acceptance criteria that includes accessibility:

Wrong: "The application must be accessible."

Right: "All user-facing pages and flows must conform to WCAG 2.1 Level AA. Automated testing with axe-core must return zero critical or serious violations. Manual keyboard navigation and screen reader testing must be completed for all new features before release."

The specificity matters: it defines what tools are used, what level is targeted, and what "done" looks like for the team.

⚠️ Common mistakes

  • Targeting Level A and calling it accessible. Level A removes only the most severe barriers. A site that is Level A compliant still lacks colour contrast, visible focus, and proper error messages — and is not legally compliant in jurisdictions that reference AA.
  • Treating WCAG as optional until there is a lawsuit. By the time litigation starts, the damage is done. Accessibility built in from the start costs a fraction of accessibility retrofitted after launch — and legal action is the least of the costs compared to the users being excluded every day.
  • Confusing WCAG 2.1 and 2.2. WCAG 2.2 is backward-compatible — anything compliant with 2.2 is also compliant with 2.1. The new criteria in 2.2 primarily address focus, dragging interactions, and target size. New projects should target 2.2.

🎯 Practice task

Spend 20 minutes mapping WCAG to a real product.

  1. Pick a product you test or use regularly. State its current accessibility conformance target (if it has one). If it does not, write the target it should have based on its audience and legal context.
  2. Choose two Level A criteria (from the Perceivable and Operable principles) and verify whether the product currently meets them. Write pass or fail with evidence.
  3. Choose one Level AA criterion and do the same.

This exercise anchors the abstract standard to a real product and a real test result. The next lesson shows you which WCAG failures appear most frequently in real audits — and how to recognise them quickly.

// tip to track lessons you complete and pick up where you left off across devices.