WordPress Accessibility: Complete WCAG 2.2 Compliance Guide

WordPress accessibility ensures your website works for users with disabilities by following Web Content Accessibility Guidelines (WCAG). WCAG 2.2 compliance isn't just ethical—it's increasingly required by law and affects 1.3 billion people worldwide who live with disabilities.

What is WordPress Accessibility?

WordPress accessibility means designing and developing websites that all users can navigate, understand, and interact with effectively, regardless of their abilities. This includes users who rely on screen readers, keyboard navigation, voice commands, or have visual, auditory, motor, or cognitive impairments.

According to the World Health Organization, 1.3 billion people experience significant disability (2023). The WebAIM Screen Reader Survey found that 87% of screen reader users have JavaScript enabled, making WordPress's dynamic functionality accessible when properly implemented.

Accessibility compliance follows the Web Content Accessibility Guidelines (WCAG), currently at version 2.2. These guidelines organize requirements into four principles:

• Perceivable: Information must be presentable in ways users can perceive
• Operable: Interface components must be operable by all users
• Understandable: Information and UI operation must be understandable
• Robust: Content must be robust enough for various assistive technologies

WCAG 2.2 Requirements for WordPress

WCAG 2.2 introduces nine new success criteria beyond WCAG 2.1, specifically addressing mobile accessibility and cognitive disabilities. Level AA compliance—the legal standard in most jurisdictions—requires meeting 50 success criteria.

Critical WCAG 2.2 Updates

The most significant additions for WordPress sites include:

Focus Not Obscured (Minimum) - Level AA: When keyboard focus moves to a UI component, it's not entirely hidden by author-created content. This affects WordPress modal dialogs, sticky headers, and mobile navigation overlays.

Focus Not Obscured (Enhanced) - Level AAA: No part of the focused component is hidden by author-created content.

Focus Appearance - Level AAA: The focus indicator has sufficient contrast and is at least 2 CSS pixels thick.

Dragging Movements - Level AA: All functionality that uses dragging movements also works with single pointer activation. This impacts WordPress drag-and-drop interfaces like Gutenberg block reordering.

Target Size (Minimum) - Level AA: Touch targets are at least 24×24 CSS pixels, except when inline with text or when a larger equivalent exists.

WordPress-Specific Implementation

WordPress core has been accessibility-ready since version 4.0, but theme and plugin developers must implement proper markup. Essential requirements include:

How to Choose Accessible WordPress Themes

Theme selection forms your accessibility foundation. WordPress.org requires themes to meet basic accessibility standards, but commercial themes vary widely in compliance.

Essential Accessibility Features

Semantic HTML Structure: Look for themes using proper heading hierarchy (H1-H6), semantic elements (<nav>, <main>, <aside>), and meaningful link text. Avoid themes with div-heavy structures or missing skip links.

Keyboard Navigation Support: Test theme demos using only Tab, Enter, and Arrow keys. Focus indicators should be clearly visible, and all interactive elements must be reachable without a mouse.

Color Contrast Compliance: Text must meet WCAG contrast requirements:

• Normal text: 4.5:1 contrast ratio
• Large text (18pt+ or 14pt+ bold): 3:1 contrast ratio
• UI components and graphics: 3:1 contrast ratio

Screen Reader Compatibility: Use NVDA, JAWS, or VoiceOver to test theme demos. Screen readers should announce page structure, form labels, and button purposes clearly.

Accessibility-Ready Theme Markers

WordPress.org themes with the "accessibility-ready" tag have been reviewed for:

• Skip links implementation
• Keyboard navigation support
• Proper form labeling
• Color contrast compliance
• Screen reader compatibility

However, this tag doesn't guarantee full WCAG 2.2 compliance. Always test themes thoroughly with your content and required plugins.

Popular Accessible Themes

Twenty Twenty-Four: WordPress's default theme includes comprehensive accessibility features, proper ARIA implementation, and has been tested with multiple assistive technologies.

Astra: Offers accessibility options in both free and pro versions, including skip links, keyboard navigation, and screen reader text options.

GeneratePress: Lightweight theme with strong accessibility foundation and extensive customization options that maintain compliance.

WordPress Plugin Accessibility Audits

Plugin compatibility significantly impacts site accessibility. According to Tenon.io, plugins cause 34% of accessibility issues on WordPress sites (2023).

Plugin Selection Criteria

Screen Reader Compatibility: Test plugins with NVDA or VoiceOver. Forms should have proper labels, buttons should announce their purpose, and dynamic content updates should be announced.

Keyboard Navigation: All plugin functionality must work without a mouse. Modal dialogs need proper focus management, dropdown menus should respond to arrow keys, and escape keys should close overlays.

ARIA Implementation: Complex widgets need proper ARIA roles, states, and properties. Tabs should use role="tablist", accordions need aria-expanded, and live regions should announce dynamic updates.

Common Plugin Issues

Contact Form 7: Popular but requires manual accessibility improvements. Add proper labels, fieldset grouping, and error message associations using aria-describedby.

WooCommerce: E-commerce functionality has improved but still needs attention to:

• Product image alt text
• Shopping cart updates announced to screen readers
• Checkout form validation feedback
• Filter controls with proper labels

Slider Plugins: Many carousel and slider plugins fail accessibility tests. Look for plugins supporting:

• Play/pause controls
• Keyboard navigation
• Screen reader announcements
• Reduced motion preferences

Accessibility Testing Tools for Plugins

axe DevTools: Browser extension identifying accessibility issues with specific WCAG references and remediation guidance.

WAVE: Web accessibility evaluation tool highlighting errors, alerts, and structural elements visually on your page.

Lighthouse Accessibility Audit: Built into Chrome DevTools, provides automated accessibility scoring and actionable recommendations.

Pa11y: Command-line tool for automated accessibility testing that integrates with CI/CD pipelines covered in our WordPress CI/CD Pipeline guide.

Screen Reader Testing and Implementation

Screen reader testing reveals how assistive technology users actually experience your WordPress site. According to the WebAIM Screen Reader Survey, 53.7% of users rely on NVDA, 30.4% use JAWS, and 11.2% use VoiceOver (2023).

Screen Reader Testing Process

Content Structure Testing: Navigate using heading shortcuts (H key in NVDA/JAWS). Headings should create a logical outline, with H1 for page titles and H2-H6 for subsections without skipping levels.

Link Context Testing: Screen readers can list all links out of context. Links like "click here" or "read more" provide no information. Use descriptive link text or add screen reader text:

<a href="/services">
  Read more
  <span class="screen-reader-text"> about our web development services</span>
</a>

Form Navigation: Test form completion using only screen reader navigation. Labels should be properly associated with inputs, required fields should be announced, and error messages should be read automatically.

Dynamic Content Updates: AJAX content updates must announce changes to screen readers using ARIA live regions:

<div aria-live="polite" id="search-results">
  <p>5 results found for "WordPress hosting"</p>
</div>

WordPress Screen Reader Implementation

Skip Links: WordPress themes should include skip links to main content, bypassing navigation:

<a class="screen-reader-text skip-link" href="#content">
  Skip to content
</a>

Alternative Text: All images need descriptive alt text. Decorative images should have empty alt attributes (alt="") to avoid clutter.

Table Headers: Data tables require proper header associations using scope attributes or headers/id relationships.

Keyboard Navigation Best Practices

Keyboard accessibility ensures users who cannot use a mouse can fully navigate your WordPress site. This includes users with motor disabilities, visual impairments, or those who prefer keyboard shortcuts.

Focus Management Principles

Visible Focus Indicators: Focus outlines must be clearly visible with sufficient contrast. WordPress themes often remove default browser focus styles without providing alternatives:

/* Bad: removes focus indicator */
button:focus { outline: none; }

/* Good: provides custom focus indicator */
button:focus {
  outline: 2px solid #005fcc;
  outline-offset: 2px;
}

Logical Tab Order: Focus should move through interactive elements in a meaningful sequence. Use tabindex="0" for custom interactive elements and tabindex="-1" for programmatically focused elements.

Focus Trapping: Modal dialogs must trap focus within the dialog until closed. The Gutenberg editor implements this pattern correctly for block settings panels.

WordPress Keyboard Navigation Patterns

Menu Navigation: WordPress menus should support arrow key navigation for submenus, Enter/Space activation, and Escape to close dropdowns.

Gutenberg Block Editor: The block editor provides comprehensive keyboard shortcuts. Users can navigate blocks with Tab, select blocks with Enter, and access block settings with Shift+Tab.

Comment Forms: Ensure all form fields are keyboard accessible, with proper tab order from name to email to comment text area.

Color Contrast and Visual Design

Color contrast affects users with low vision, color blindness, and those viewing sites in bright sunlight or on low-quality displays. WCAG 2.2 requires specific contrast ratios for different content types.

Contrast Requirements

Text Contrast: Normal text requires 4.5:1 contrast against background colors. Large text (18pt regular or 14pt bold) needs 3:1 contrast.

UI Component Contrast: Form inputs, buttons, and focus indicators need 3:1 contrast against adjacent colors.

Graphical Elements: Icons, charts, and meaningful graphics require 3:1 contrast for essential information.

WordPress Color Implementation

Theme Customizer Accessibility: When customizing colors through WordPress Customizer, test contrast ratios using browser developer tools or online calculators.

Gutenberg Block Colors: Custom color palettes in Gutenberg should pre-validate contrast ratios to prevent accessibility issues:

// Add accessible color palette
add_theme_support( 'editor-color-palette', array(
    array(
        'name' => 'Dark Blue',
        'slug' => 'dark-blue',
        'color' => '#003366', // Tested for 4.5:1 contrast on white
    ),
    array(
        'name' => 'Light Gray',
        'slug' => 'light-gray',
        'color' => '#666666', // Tested for 4.5:1 contrast on white
    ),
) );

Link Identification: Links must be identifiable without relying solely on color. Use underlines, icons, or other visual indicators alongside color changes.

ARIA Landmarks and Semantic Structure

ARIA (Accessible Rich Internet Applications) landmarks help screen reader users navigate page sections efficiently. WordPress themes should implement proper landmark roles and semantic HTML.

Essential ARIA Landmarks

Navigation Landmarks: Primary navigation should use role="navigation" or semantic <nav> elements. Multiple navigation areas need distinct labels:

<nav aria-label="Primary navigation">
  <!-- Main menu items -->
</nav>
<nav aria-label="Footer links">
  <!-- Footer navigation -->
</nav>

Content Landmarks: Page content areas should use role="main" or semantic <main> elements. Sidebars use role="complementary" or <aside> elements.

Search Landmarks: Search functionality should be marked with role="search":

<form role="search" method="get" action="<?php echo home_url( '/' ); ?>">
  <label for="search-field">Search site</label>
  <input id="search-field" type="search" name="s" />
  <button type="submit">Search</button>
</form>

WordPress ARIA Implementation

Dynamic Content: WordPress sites with AJAX functionality need proper ARIA live regions to announce updates:

<!-- Shopping cart updates -->
<div aria-live="polite" aria-atomic="true" id="cart-status">
  2 items in cart
</div>

<!-- Form validation messages -->
<div aria-live="assertive" id="form-errors">
  Please enter a valid email address
</div>

Custom Post Type Archives: Archive pages should identify their content type using appropriate headings and landmarks:

<main role="main">
  <h1>Product Catalog</h1>
  <section aria-labelledby="filter-heading">
    <h2 id="filter-heading">Filter Products</h2>
    <!-- Filter controls -->
  </section>
  <section aria-labelledby="results-heading">
    <h2 id="results-heading">Search Results</h2>
    <!-- Product grid -->
  </section>
</main>

Form Accessibility Standards

WordPress forms appear throughout sites—contact forms, comment forms, search boxes, and e-commerce checkouts. Accessible forms require proper labeling, error handling, and instruction provision.

Form Label Requirements

Explicit Labels: Every form input needs an associated label using the for attribute:

<label for="email-address">Email Address (Required)</label>
<input type="email" id="email-address" name="email" required 
       aria-describedby="email-help" />
<div id="email-help">We'll never share your email address</div>

Fieldset Grouping: Related form controls should be grouped using <fieldset> and <legend> elements:

<fieldset>
  <legend>Shipping Address</legend>
  <label for="ship-name">Name</label>
  <input type="text" id="ship-name" name="shipping_name" />
  <label for="ship-address">Street Address</label>
  <input type="text" id="ship-address" name="shipping_address" />
</fieldset>

Error Handling and Validation

Error Identification: Form errors must be clearly identified and associated with relevant fields using aria-describedby:

<label for="phone">Phone Number</label>
<input type="tel" id="phone" name="phone" aria-describedby="phone-error" 
       aria-invalid="true" />
<div id="phone-error" role="alert">
  Please enter a valid phone number
</div>

Success Confirmation: Form submission success should be announced to screen readers using ARIA live regions or focus management to confirmation messages.

WordPress Comment Form Accessibility

The default WordPress comment form includes basic accessibility features but often needs enhancement:

// Customize comment form for better accessibility
$comment_form_args = array(
    'title_reply' => '<span id="reply-title">Leave a Reply</span>',
    'label_submit' => 'Post Comment',
    'comment_field' => '<p><label for="comment">Comment (Required)</label><textarea id="comment" name

Colton Joseph

Founder & Lead Developer

20+ years full-stack development, WordPress, AI tools & agents

Colton is the founder of TopSyde with 20+ years of full-stack development experience spanning WordPress, cloud infrastructure, and AI-powered tooling. He specializes in performance optimization, server architecture, and building AI agents for automated site management.

XLinkedIn