Reference Lab

WCAG 2.2 Example Library

0 Overview

Browse all 86 WCAG 2.2 success criteria as production-ready example routes. Each route now includes an overview, official W3C ACT rules where published, implementation comparison, manual validation guidance, test-source labeling, and official WCAG resources.

86Criteria
4Principles
86Routes
38Criteria with W3C ACT rules

1 Perceivable

29 criteria in this principle with implementation examples, official ACT coverage where available, and source coverage labels.

CriterionNameLevelCoverageW3C ACTExample
1.1.1
Non-text Content
Text Alternatives
A
AXE
9 rules
7 approved • 1 proposed • 1 deprecated
Equivalent text lets screen reader users understand non-text content.
1.2.1
Audio-only and Video-only (Prerecorded)
Time-based Media
A
AXE
9 rules
9 proposed
Users who cannot hear or see the media still need access to the same information.
1.2.2
Captions (Prerecorded)
Time-based Media
A
AXE
3 rules
3 proposed
Captions make prerecorded audio content available to deaf and hard-of-hearing users.
1.2.3
Audio Description or Media Alternative (Prerecorded)
Time-based Media
A
Manual
4 rules
4 proposed
Critical visual information must be available to people who cannot see the video.
1.2.4
Captions (Live)
Time-based Media
AA
Manual
None yet
Live captions are needed for real-time access to spoken information.
1.2.5
Audio Description (Prerecorded)
Time-based Media
AA
AXE
5 rules
5 proposed
Users who cannot see the video need access to important visual-only content.
1.2.6
Sign Language (Prerecorded)
Time-based Media
AAA
Manual
None yet
Some users rely on sign language rather than captions for full comprehension.
1.2.7
Extended Audio Description (Prerecorded)
Time-based Media
AAA
Manual
None yet
Some visuals require more time to describe than natural pauses allow.
1.2.8
Media Alternative (Prerecorded)
Time-based Media
AAA
Manual
4 rules
4 proposed
A full text alternative provides equivalent access without requiring video playback.
1.2.9
Audio-only (Live)
Time-based Media
AAA
Manual
None yet
Users need another way to access live audio-only content.
1.3.1
Info and Relationships
Adaptable
A
AXE
14 rules
6 approved • 7 proposed • 1 deprecated
Relationships shown visually must also be exposed in the markup.
1.3.2
Meaningful Sequence
Adaptable
A
Playwright
None yet
Meaningful sequence must survive CSS changes and assistive technology reading order.
1.3.3
Sensory Characteristics
Adaptable
A
Manual
1 rule
1 proposed
Users may not perceive color, shape, or spatial references the same way.
1.3.4
Orientation
Adaptable
AA
Playwright
1 rule
1 approved
Users may mount devices or depend on a fixed orientation.
1.3.5
Identify Input Purpose
Adaptable
AA
AXE
1 rule
1 approved
Identifying input purpose supports personalization and autofill tools.
1.3.6
Identify Purpose
Adaptable
AAA
Manual
None yet
AAA asks for programmatic identification of broader UI purpose, not just input purpose.
1.4.1
Use of Color
Distinguishable
A
AXE
None yet
Color alone cannot be the only cue for meaning or status.
1.4.2
Audio Control
Distinguishable
A
AXE
3 rules
3 proposed
Unexpected audio interferes with screen readers and concentration.
1.4.3
Contrast (Minimum)
Distinguishable
AA
AXE
2 rules
2 approved
Minimum contrast supports readability for many low-vision users.
1.4.4
Resize Text
Distinguishable
AA
AXE
2 rules
1 approved • 1 proposed
Users must be able to resize text without losing access or meaning.
1.4.5
Images of Text
Distinguishable
AA
Playwright
1 rule
1 approved
Text in images is harder to resize, translate, and adapt.
1.4.6
Contrast (Enhanced)
Distinguishable
AAA
AXE
2 rules
2 approved
AAA enhanced contrast further improves readability for low-vision users.
1.4.7
Low or No Background Audio
Distinguishable
AAA
Manual
None yet
Competing background audio makes speech harder to understand.
1.4.8
Visual Presentation
Distinguishable
AAA
Manual
None yet
AAA visual presentation supports sustained reading comfort and comprehension.
1.4.9
Images of Text (No Exception)
Distinguishable
AAA
Manual
1 rule
1 approved
AAA removes most exceptions for images of text.
1.4.10
Reflow
Distinguishable
AA
Playwright
1 rule
1 approved
Users should not need two-dimensional scrolling for ordinary content.
1.4.11
Non-text Contrast
Distinguishable
AA
Manual
None yet
Non-text UI components still need sufficient visual distinction.
1.4.12
Text Spacing
Distinguishable
AA
Playwright
3 rules
3 approved
Users often override spacing to improve readability.
1.4.13
Content on Hover or Focus
Distinguishable
AA
Playwright
None yet
Users need enough control to read and interact with revealed content.

2 Operable

34 criteria in this principle with implementation examples, official ACT coverage where available, and source coverage labels.

CriterionNameLevelCoverageW3C ACTExample
2.1.1
Keyboard
Keyboard Accessible
A
AXE
2 rules
2 approved
Keyboard access is foundational for many assistive technology users.
2.1.2
No Keyboard Trap
Keyboard Accessible
A
AXE
3 rules
3 proposed
Keyboard users must never get trapped inside a control.
2.1.3
Keyboard (No Exception)
Keyboard Accessible
AAA
Manual
2 rules
2 approved
AAA removes exceptions for keyboard operation.
2.1.4
Character Key Shortcuts
Keyboard Accessible
A
Playwright
1 rule
1 proposed
Character shortcuts often conflict with speech input and assistive tech.
2.2.1
Timing Adjustable
Enough Time
A
AXE
2 rules
2 approved
People need different amounts of time to read, understand, and respond.
2.2.2
Pause, Stop, Hide
Enough Time
A
AXE
1 rule
1 proposed
Moving content can distract users and interfere with reading.
2.2.3
No Timing
Enough Time
AAA
Manual
None yet
AAA expects timing to be unnecessary unless it is essential to the activity.
2.2.4
Interruptions
Enough Time
AAA
Manual
2 rules
2 approved
Unexpected interruptions can derail users with cognitive or attention-related disabilities.
2.2.5
Re-authenticating
Enough Time
AAA
Manual
None yet
Re-authentication should not force users to redo their work.
2.2.6
Timeouts
Enough Time
AAA
Manual
None yet
Users need notice when inactivity could cause data loss.
2.3.1
Three Flashes or Below Threshold
Seizures and Physical Reactions
A
Playwright
None yet
Rapid flashing can trigger seizures in susceptible users.
2.3.2
Three Flashes
Seizures and Physical Reactions
AAA
Playwright
None yet
AAA requires stricter avoidance of flashing content.
2.3.3
Animation from Interactions
Seizures and Physical Reactions
AAA
Playwright
None yet
Motion can cause dizziness or nausea for vestibular disorders.
2.4.1
Bypass Blocks
Navigable
A
AXE
5 rules
5 proposed
Repeated blocks should be easy to bypass.
2.4.2
Page Titled
Navigable
A
AXE
2 rules
2 approved
Descriptive titles help users orient and navigate browser tabs and history.
2.4.3
Focus Order
Navigable
A
AXE
None yet
Predictable focus order preserves meaning and usability.
2.4.4
Link Purpose (In Context)
Navigable
A
AXE
3 rules
1 approved • 2 proposed
Users should understand link purpose before activating it.
2.4.5
Multiple Ways
Navigable
AA
Playwright
None yet
Multiple ways help users locate content efficiently.
2.4.6
Headings and Labels
Navigable
AA
Playwright
2 rules
2 proposed
Good labels reduce ambiguity and scanning effort.
2.4.7
Focus Visible
Navigable
AA
Playwright
1 rule
1 approved
Users need to know where keyboard focus currently is.
2.4.8
Location
Navigable
AAA
Playwright
None yet
AAA location cues help users stay oriented in complex systems.
2.4.9
Link Purpose (Link Only)
Navigable
AAA
Playwright
5 rules
1 approved • 4 proposed
AAA expects link meaning to stand on its own without surrounding context.
2.4.10
Section Headings
Navigable
AAA
Manual
None yet
Section headings support scanning, navigation, and comprehension.
2.4.11
Focus Not Obscured (Minimum)
Navigable
AA
Playwright
None yet
Focused controls must remain at least partially visible.
2.4.12
Focus Not Obscured (Enhanced)
Navigable
AAA
Manual
None yet
Enhanced focus visibility requires the whole focused component to remain visible.
2.4.13
Focus Appearance
Navigable
AAA
Playwright
None yet
AAA defines stronger focus appearance requirements to improve detectability.
2.5.1
Pointer Gestures
Input Modalities
A
Manual
None yet
Complex gestures need a simpler alternative.
2.5.2
Pointer Cancellation
Input Modalities
A
Playwright
None yet
Pointer cancellation helps users avoid accidental activation.
2.5.3
Label in Name
Input Modalities
A
Playwright
2 rules
1 approved • 1 proposed
Speech input users rely on visible labels matching spoken commands.
2.5.4
Motion Actuation
Input Modalities
A
Manual
2 rules
2 proposed
Motion-based input needs a conventional alternative.
2.5.5
Target Size (Enhanced)
Input Modalities
AAA
Manual
None yet
Larger targets reduce accidental activation and improve motor accessibility.
2.5.6
Concurrent Input Mechanisms
Input Modalities
AAA
Manual
None yet
Content should not block available input methods without an essential reason.
2.5.7
Dragging Movements
Input Modalities
AA
Playwright
None yet
Dragging motions need a simpler single-pointer alternative.
2.5.8
Target Size (Minimum)
Input Modalities
AA
AXE
None yet
Minimum target size improves touch and pointer accuracy.

3 Understandable

21 criteria in this principle with implementation examples, official ACT coverage where available, and source coverage labels.

CriterionNameLevelCoverageW3C ACTExample
3.1.1
Language of Page
Readable
A
AXE
4 rules
2 approved • 1 proposed • 1 deprecated
Language metadata helps assistive technologies choose pronunciation rules.
3.1.2
Language of Parts
Readable
AA
AXE
2 rules
1 approved • 1 proposed
Language changes within content should be programmatically identified.
3.1.3
Unusual Words
Readable
AAA
Manual
None yet
AAA helps users understand uncommon terminology.
3.1.4
Abbreviations
Readable
AAA
Manual
None yet
Users should be able to identify the full meaning of abbreviations.
3.1.5
Reading Level
Readable
AAA
Manual
None yet
AAA supports users who benefit from easier reading levels.
3.1.6
Pronunciation
Readable
AAA
Manual
None yet
Pronunciation cues can prevent misunderstanding when meaning depends on spoken form.
3.2.1
On Focus
Predictable
A
Playwright
None yet
Focus should not surprise users by changing the interface.
3.2.2
On Input
Predictable
A
Playwright
None yet
Input changes should not unexpectedly shift context.
3.2.3
Consistent Navigation
Predictable
AA
Manual
None yet
Consistency reduces relearning and navigation cost.
3.2.4
Consistent Identification
Predictable
AA
Manual
None yet
Consistent identification helps users build reliable expectations.
3.2.5
Change on Request
Predictable
AAA
Manual
2 rules
2 approved
AAA favors user-initiated changes over automatic ones.
3.2.6
Consistent Help
Predictable
A
Manual
None yet
WCAG 2.2 adds consistency requirements for repeated help mechanisms.
3.3.1
Error Identification
Input Assistance
A
Playwright
1 rule
1 proposed
Users need explicit text describing what went wrong.
3.3.2
Labels or Instructions
Input Assistance
A
Playwright
None yet
Users need persistent guidance on what information is required.
3.3.3
Error Suggestion
Input Assistance
AA
Playwright
None yet
Helpful correction suggestions reduce frustration and rework.
3.3.4
Error Prevention (Legal, Financial, Data)
Input Assistance
AA
Manual
None yet
Important commitments and data changes need error prevention.
3.3.5
Help
Input Assistance
AAA
Manual
None yet
AAA help supports users during data entry and decision-making.
3.3.6
Error Prevention (All)
Input Assistance
AAA
Manual
None yet
AAA extends submission error prevention to all user-provided information.
3.3.7
Redundant Entry
Input Assistance
A
Manual
None yet
WCAG 2.2 reduces unnecessary memory and typing burden.
3.3.8
Accessible Authentication (Minimum)
Input Assistance
AA
Playwright
None yet
Authentication should not depend on memory, transcription, or puzzle solving alone.
3.3.9
Accessible Authentication (Enhanced)
Input Assistance
AAA
Playwright
None yet
AAA further reduces cognitive barriers during authentication.

4 Robust

2 criteria in this principle with implementation examples, official ACT coverage where available, and source coverage labels.

CriterionNameLevelCoverageW3C ACTExample
4.1.2
Name, Role, Value
Compatible
A
AXE
16 rules
12 approved • 3 proposed • 1 deprecated
Assistive technologies rely on machine-readable control semantics.
4.1.3
Status Messages
Compatible
AA
Playwright
None yet
Users need important status updates even when focus stays put.