Free WCAG 2.2 Checklist for Developers — Every Success Criterion Explained
Back to Blog
Blyxo Team
5 min read
AccessibilityWCAGChecklistWeb Development

WCAG 2.2 has 55 success criteria at Level A and AA. Reading the official spec is like reading a legal contract. This checklist translates every criterion into plain language with practical implementation notes.

Bookmark this page. Use it during code reviews, QA testing, and accessibility audits.

Principle 1: Perceivable

Content must be presentable in ways all users can perceive.

1.1 Text Alternatives

1.1.1 Non-text Content (A) Every image, icon, chart, and CAPTCHA needs a text alternative.

  • Informative images: descriptive alt text (alt="Bar chart showing 40% increase in Q3 revenue")
  • Decorative images: empty alt (alt="") or CSS background
  • Functional images (buttons/links): alt describes the action (alt="Search")
  • Complex images: provide a longer description via aria-describedby or adjacent text

1.2 Time-based Media

1.2.1 Audio-only and Video-only (A) Provide transcripts for audio. Provide audio description or transcript for video.

1.2.2 Captions (A) All pre-recorded video with audio must have synchronised captions.

1.2.3 Audio Description or Media Alternative (A) Pre-recorded video needs audio description or a full text transcript.

1.2.4 Captions Live (AA) Live video with audio must have real-time captions.

1.2.5 Audio Description (AA) Pre-recorded video must have audio description for visual-only content.

1.3 Adaptable

1.3.1 Info and Relationships (A) Structure conveyed visually must also be conveyed programmatically: headings use <h1>-<h6>, lists use <ul>/<ol>, tables use <table> with <th>, form fields have <label>.

1.3.2 Meaningful Sequence (A) Reading order in the DOM must match the visual order. Don't use CSS to rearrange content in a way that changes meaning.

1.3.3 Sensory Characteristics (A) Don't rely solely on shape, size, position, or colour to convey information. "Click the red button" fails. "Click the Submit button" passes.

1.3.4 Orientation (AA) Don't lock content to portrait or landscape unless essential (e.g., a piano app).

1.3.5 Identify Input Purpose (AA) Use autocomplete attributes on form fields for personal data (name, email, address, phone).

1.4 Distinguishable

1.4.1 Use of Colour (A) Don't use colour as the only way to convey information. Error fields need an icon or text label, not just a red border.

1.4.2 Audio Control (A) If audio plays automatically for more than 3 seconds, provide a way to pause or stop it.

1.4.3 Contrast (Minimum) (AA) Text: 4.5:1 ratio against background. Large text (18pt+ or 14pt+ bold): 3:1 ratio.

1.4.4 Resize Text (AA) Text must be resizable up to 200% without losing content or functionality.

1.4.5 Images of Text (AA) Don't use images of text. Use actual text styled with CSS. Exceptions: logos, text that's part of a photo.

1.4.10 Reflow (AA) Content must reflow at 320px width (400% zoom) without horizontal scrolling. No two-dimensional scrolling except for content that requires it (data tables, maps).

1.4.11 Non-text Contrast (AA) UI components and graphical objects need 3:1 contrast against adjacent colours. Applies to form borders, icons, chart elements.

1.4.12 Text Spacing (AA) Content must remain readable when users override: line height to 1.5x, paragraph spacing to 2x, letter spacing to 0.12em, word spacing to 0.16em.

1.4.13 Content on Hover or Focus (AA) Tooltips and popovers must be: dismissible (Escape key), hoverable (user can move mouse into the tooltip), and persistent (stays until dismissed).

Principle 2: Operable

Users must be able to operate the interface.

2.1 Keyboard Accessible

2.1.1 Keyboard (A) All functionality must work with keyboard alone. Tab to navigate, Enter/Space to activate, arrow keys within components.

2.1.2 No Keyboard Trap (A) Users must be able to navigate away from every component using keyboard. No focus traps (except intentional ones like modals, which need an Escape key exit).

2.1.4 Character Key Shortcuts (A) If you use single-character keyboard shortcuts, let users remap or disable them.

2.2 Enough Time

2.2.1 Timing Adjustable (A) If content has a time limit, let users turn off, adjust, or extend it. Session timeouts must warn 20+ seconds before expiry.

2.2.2 Pause, Stop, Hide (A) Moving, blinking, or auto-updating content must have a mechanism to pause or stop it. Carousels, news tickers, animations — all need controls.

2.3 Seizures and Physical Reactions

2.3.1 Three Flashes or Below Threshold (A) Nothing flashes more than 3 times per second.

2.4 Navigable

2.4.1 Bypass Blocks (A) Provide a "Skip to main content" link as the first focusable element.

2.4.2 Page Titled (A) Every page has a descriptive <title> that identifies its topic.

2.4.3 Focus Order (A) Tab order follows a logical sequence matching the visual layout.

2.4.4 Link Purpose (A) Every link's purpose is clear from its text (or text + context). Avoid "click here" and "read more" without context.

2.4.5 Multiple Ways (AA) Provide more than one way to find pages: navigation menu, search, site map.

2.4.6 Headings and Labels (AA) Headings and labels describe the topic or purpose of their content.

2.4.7 Focus Visible (AA) Keyboard focus indicator must be visible. Never add outline: none without a custom focus style.

2.4.11 Focus Not Obscured (AA) (New in 2.2) Focused elements must not be entirely hidden by sticky headers, banners, or overlays. Use scroll-padding-top.

2.5 Input Modalities

2.5.1 Pointer Gestures (A) Multi-point or path-based gestures (pinch, swipe) must have single-pointer alternatives.

2.5.2 Pointer Cancellation (A) For click/tap actions, use mouseup/touchend (not mousedown/touchstart) so users can cancel by moving away.

2.5.3 Label in Name (A) The accessible name of a component must contain its visible label text.

2.5.4 Motion Actuation (A) If shaking or tilting triggers functionality, provide a UI alternative and let users disable motion.

2.5.7 Dragging Movements (AA) (New in 2.2) Drag-and-drop must have a click-based alternative (buttons, dropdowns).

2.5.8 Target Size (Minimum) (AA) (New in 2.2) Interactive targets must be at least 24x24 CSS pixels.

Principle 3: Understandable

Content and operation must be understandable.

3.1 Readable

3.1.1 Language of Page (A) Set lang attribute on the <html> element (<html lang="en">).

3.1.2 Language of Parts (AA) If content switches language mid-page, mark it: <span lang="fr">Bonjour</span>.

3.2 Predictable

3.2.1 On Focus (A) Moving focus to a component must not trigger a change of context (page navigation, form submission).

3.2.2 On Input (A) Changing a form input must not automatically trigger a change of context unless the user is warned.

3.2.6 Consistent Help (A) (New in 2.2) Help mechanisms must appear in the same relative location on every page.

3.3 Input Assistance

3.3.1 Error Identification (A) Errors are identified and described in text. Don't rely solely on colour.

3.3.2 Labels or Instructions (A) Form fields have labels. Required fields are indicated. Expected formats are described.

3.3.3 Error Suggestion (AA) When an error is detected and a fix is known, suggest it to the user.

3.3.4 Error Prevention (AA) For legal, financial, or data-deletion actions: let users review, confirm, and reverse submissions.

3.3.7 Redundant Entry (A) (New in 2.2) Don't require re-entry of previously provided information in the same process.

3.3.8 Accessible Authentication (AA) (New in 2.2) Don't require cognitive tests (puzzle CAPTCHAs) as the sole login method. Support password managers.

Principle 4: Robust

Content must be compatible with current and future tools.

4.1 Compatible

4.1.2 Name, Role, Value (A) Custom components must expose their name, role, and state to assistive technologies via ARIA.

4.1.3 Status Messages (AA) Status messages (success alerts, error counts, progress updates) must be announced by screen readers without receiving focus. Use role="status" or aria-live="polite".

Using this checklist

This covers all 55 Level A and AA criteria in WCAG 2.2. For a complete audit:

  1. Run automated tools to catch the ~30-40% of issues detectable by code analysis
  2. Walk through this checklist manually for each page template
  3. Test with keyboard navigation (Tab, Enter, Escape, arrow keys)
  4. Test with a screen reader (VoiceOver on Mac, NVDA on Windows)
  5. Test at 200% zoom and 320px viewport width

No single tool or checklist catches everything. Automated scanning plus manual review plus real-user testing gives the best coverage.


Found this checklist useful? We maintain an automated version of these checks at Blyxo — scan your site and see which criteria pass, which fail, and what to fix first.

Ready to improve your website's accessibility?

Blyxo helps teams find and fix accessibility issues with AI-powered testing and developer-friendly recommendations.

Blog | Blyxo