Implementing WCAG 2.2: A Comprehensive Accessibility Guide

Last updated: 3 Feb, 2025

This guide was written by Adam.

This guide provides actionable steps to meet WCAG 2.2 Level AA standards, making your website accessible to all users.

It is intended as a practical guide for anyone making user-facing content that can be accessed by a browser.

Understanding WCAG 2.2

WCAG 2.2 builds on WCAG 2.1 with additional success criteria to address emerging accessibility needs. It maintains the four foundational principles known as POUR:

Perceivable
Information and user interface components must be presentable to users in ways they can perceive.
Operable
User interface components and navigation must be operable by all users.
Understandable
Information and the operation of user interface must be understandable.
Robust
Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies.

What's New in WCAG 2.2

  • Focus Appearance (2.4.11): Minimum focus indicator requirements
  • Dragging Movements (2.5.7): Alternatives to drag-and-drop
  • Target Size (2.5.8): Minimum size for touch targets
  • Consistent Help (3.2.6): Consistent placement of help mechanisms
  • Redundant Entry (3.3.7): Minimize re-entry of information

Text Alternatives (Success Criterion 1.1.1)

Provide text alternatives for any non-text content so it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

Implementation Checklist

  • All meaningful images have descriptive alt attributes
  • Decorative images have empty alt attributes (alt="") and role="presentation"
  • Complex images (charts, graphs) have detailed descriptions nearby or through longdesc
  • Icons and icon fonts have text alternatives
  • Form buttons have descriptive text (avoid "click here")
  • SVGs with meaningful content have aria-label or text alternatives

Code Examples

<!-- Informative image -->
<img src="chart.png" alt="Bar chart showing sales growth: 2018 $1.2M, 2019 $1.5M, 2020 $2.1M">

<!-- Decorative image -->
<img src="divider.png" alt="" role="presentation">

<!-- SVG with text alternative -->
<svg aria-labelledby="svg-title" role="img">
    <title id="svg-title">Company logo featuring a mountain and sun</title>
    <!-- SVG paths -->
</svg>

Keyboard Navigation (Success Criteria 2.1.1, 2.1.2, 2.4.3, 2.4.11, 2.5.7)

All functionality must be available through a keyboard interface without requiring specific timings for individual keystrokes.

Implementation Checklist

  • All interactive elements are reachable via keyboard (Tab key)
  • Logical tab order matches visual flow
  • Visible focus indicators that meet 2.4.11 requirements (3:1 contrast, covers at least the outline)
  • No keyboard traps (users can tab in and out of all components)
  • Skip links available for bypassing repetitive content
  • Custom widgets implement proper keyboard interactions (ARIA patterns)
  • Any functionality requiring dragging has a simple pointer alternative (2.5.7)

Focus Appearance Requirements (2.4.11)

Focus indicators must:

  • Have at least a 3:1 contrast ratio between the focused and unfocused states
  • Be at least as large as a 1px solid line around the component
  • Not be obscured by other content when focused
button:focus {
    outline: 2px solid #0056b3; /* 3:1 contrast with white */
    outline-offset: 2px;
}

Color and Contrast (Success Criteria 1.4.1, 1.4.3, 1.4.11)

Ensure sufficient color contrast and don't rely on color alone to convey information.

Implementation Checklist

  • Normal text has at least 4.5:1 contrast ratio against background
  • Large text (18pt+/24px+ or bold 14pt+/18.5px+) has at least 3:1 contrast
  • User interface components and graphical objects have 3:1 contrast
  • Color is not the only means of conveying information (e.g., form errors)
  • Interactive elements have distinct states (hover, focus, active)
  • Non-text contrast for UI components and graphical objects (1.4.11)

Non-Text Contrast (1.4.11)

These elements need 3:1 contrast against adjacent colors:

Content Structure (Success Criteria 1.3.1, 2.4.6, 2.4.10)

Create content that can be presented in different ways without losing information or structure.

Implementation Checklist

  • Proper heading hierarchy (h1-h6)
  • Lists marked up as ul, ol, or dl
  • Data tables use proper th, scope, and caption
  • Landmark regions (e.g., header, main, nav, footer)
  • Page titles that describe page content
  • Section headings that describe their content
  • Reading order matches visual order

Semantic HTML Examples

<!-- Proper heading structure -->
<h1>Page Title</h1>
<h2>Section Heading</h2>
<h3>Subsection Heading</h3>

<!-- Accessible table -->
<table>
    <caption>Monthly Sales Report</caption>
    <thead>
        <tr>
            <th scope="col">Month</th>
            <th scope="col">Sales</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <th scope="row">January</th>
            <td>$12,000</td>
        </tr>
    </tbody>
</table>

Focus Management (Success Criteria 2.4.3, 2.4.11, 2.4.13)

Ensure proper focus management for keyboard and screen reader users.

Implementation Checklist

  • Focus order follows logical reading sequence
  • Focus indicators meet 2.4.11 requirements
  • Focus is not trapped in any component
  • Focus moves logically in modal dialogs
  • Content that appears on focus remains visible until focus moves
  • Important notifications are programmatically determinable

Focus Management in Single Page Apps

When content changes dynamically:

  1. Move focus to new content (unless it would disrupt user task)
  2. Provide announcement via ARIA live region
  3. Ensure focus remains within any opened modal
  4. Return focus to triggering element when modal closes

Target Sizes (Success Criterion 2.5.8)

Ensure touch targets are large enough for easy activation.

Implementation Checklist

  • Touch targets are at least 24px by 24px (CSS pixels)
  • Exception: Spacing of at least 24px exists between adjacent targets
  • Exception: Targets in sentences can be smaller
  • Exception: The target size is controlled by the browser
  • Links in paragraphs have sufficient spacing

Implementation Techniques

Target Size Implementation Options
Technique Example
Increase element size padding: 12px; /* Makes total size ≥24px */
Increase spacing margin: 12px; /* Creates 24px gap */
Use CSS transforms transform: scale(1.5);

Multimedia Accessibility (Success Criteria 1.2.1-1.2.9)

Provide alternatives for time-based media to ensure accessibility.

Implementation Checklist

  • Pre-recorded audio has transcripts
  • Pre-recorded video has captions
  • Live video has real-time captions when possible
  • Video with important visual information has audio description
  • Media players have accessible controls
  • No auto-playing media (or provide easy pause/stop controls)
  • Custom media players follow ARIA Authoring Practices

Accessible Media Implementation

<video controls>
    <source src="video.mp4" type="video/mp4">
    <track src="captions.vtt" kind="captions" 
           srclang="en" label="English" default>
    <track src="descriptions.vtt" kind="descriptions" 
           srclang="en" label="English Descriptions">
    <track src="chapters.vtt" kind="chapters" 
           srclang="en">
</video>

Forms and Interactive Elements (Success Criteria 3.3.1-3.3.7, 4.1.2, 4.1.3)

Make all forms and interactive components accessible and understandable.

Implementation Checklist

  • All form fields have associated label elements
  • Required fields are clearly indicated (text and visual)
  • Error messages are descriptive and suggest corrections
  • Custom controls have proper ARIA roles and attributes
  • Buttons have descriptive text
  • Form submission is controllable (no unexpected changes)
  • Minimize redundant entry (3.3.7) by remembering user inputs
  • Status messages are programmatically determinable (4.1.3)

Accessible Form Example

<form>
    <fieldset>
        <legend>Contact Information</legend>
        
        <div>
            <label for="name">Full Name <span class="required" aria-hidden="true">*</span></label>
            <input type="text" id="name" name="name" required
                   aria-required="true">
        </div>
        
        <div>
            <label for="email">Email Address <span class="required" aria-hidden="true">*</span></label>
            <input type="email" id="email" name="email" required
                   aria-required="true"
                   aria-describedby="email-help">
            <div id="email-help">We'll never share your email.</div>
        </div>
        
        <button type="submit">Submit Contact Request</button>
        
        <div role="status" aria-live="polite" id="form-status"></div>
    </fieldset>
</form>

Testing for Accessibility (Success Criteria 4.1.1, 4.1.2, 4.1.3)

Comprehensive accessibility testing combines automated tools, manual testing, and user testing.

Testing Methodology

  1. Automated Testing (catches ~30% of issues):
  2. Manual Testing:
    • Keyboard-only navigation (Tab, Shift+Tab, Enter, Space)
    • Screen reader testing (NVDA, VoiceOver, JAWS)
    • Zoom testing (200% zoom at 1280px width)
    • Color contrast verification
    • Target size measurement
    • Focus management verification
  3. User Testing:
    • Include people with various disabilities
    • Test with different assistive technologies
    • Test on various devices and browsers

WCAG 2.2 Specific Tests

  • Focus Appearance (2.4.11): Verify focus indicators meet contrast and size requirements
  • Dragging (2.5.7): Ensure all drag operations have simple pointer alternatives
  • Target Size (2.5.8): Measure touch targets (≥24px)
  • Redundant Entry (3.3.7): Verify previously entered info isn't requested again

Additional Resources

Official Documentation

Practical Guides

Testing Tools