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 is an ethical baseline, and it is increasingly required by law. It 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 move through, 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 interpreted reliably by a wide range of browsers and 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 55 success criteria: every Level A and Level AA criterion in the standard.

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 obscured 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 obscured 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. Core 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 comes first. 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 support is the next test. Try 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.

Text must also 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

For screen reader compatibility, use NVDA, JAWS, or VoiceOver on 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-Five, a recent WordPress 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 is a lightweight theme with a 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

Test plugins with NVDA or VoiceOver for screen reader compatibility. Forms should have proper labels, buttons should announce their purpose, and dynamic content updates should be announced.

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.

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 is 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

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 is a browser extension that identifies accessibility issues with specific WCAG references and remediation guidance.

WAVE is a web accessibility evaluation tool highlighting errors, alerts, and structural elements visually on your page.

The Lighthouse Accessibility Audit is built into Chrome DevTools and provides automated accessibility scoring and actionable recommendations.

Pa11y is a 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 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

Start with content structure. Move through the page 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.

Screen readers can also 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>

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.

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

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

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

All images need descriptive alt text. Decorative images should have empty alt attributes (alt="") to avoid clutter. 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 operate your WordPress site. This includes users with motor disabilities, visual impairments, or those who prefer keyboard shortcuts.

Focus Management Principles

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;
}

Focus should move through interactive elements in a meaningful sequence. Use tabindex="0" for custom interactive elements and tabindex="-1" for programmatically focused elements. Modal dialogs must trap focus within the dialog until closed, and the Gutenberg editor implements this pattern correctly for block settings panels.

WordPress Keyboard Navigation Patterns

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

The Gutenberg block editor provides comprehensive keyboard shortcuts. Users can move between blocks with Tab, select blocks with Enter, and access block settings with Shift+Tab.

On comment forms, ensure all 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

Normal text requires 4.5:1 contrast against background colors. Large text (18pt regular or 14pt bold) needs 3:1 contrast. Form inputs, buttons, and focus indicators need 3:1 contrast against adjacent colors. Icons, charts, and meaningful graphics require 3:1 contrast for the information they convey.

WordPress Color Implementation

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

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
    ),
) );

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 move between page sections efficiently. WordPress themes should implement proper landmark roles and semantic HTML.

Essential ARIA 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>

Page content areas should use role="main" or semantic <main> elements. Sidebars use role="complementary" or <aside> elements. 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

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>

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

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>

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

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>

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'          => 'Leave a Reply',
    'title_reply_before'   => '<h2 id="reply-title" class="comment-reply-title">',
    'title_reply_after'    => '</h2>',
    'label_submit'         => 'Post Comment',
    'comment_notes_before' => '<p id="comment-notes">Your email address will not be published. All fields marked (Required) must be filled in.</p>',
    'comment_field'        => '<p><label for="comment">Comment (Required)</label><textarea id="comment" name="comment" cols="45" rows="8" required aria-describedby="comment-notes"></textarea></p>',
);

comment_form( $comment_form_args );

Two details matter here. The reply heading uses title_reply_before to render a real <h2>, so it fits the page's heading outline (the default is an <h3>, which can skip a level on themes where the post title is the only <h1>). And "(Required)" is written out in the label text instead of relying on a red asterisk, so screen reader users and people who can't see color both get the instruction. If you change the name and email fields too, pass them through the fields argument with the same pattern: a visible <label for>, the required attribute, and autocomplete="name" or autocomplete="email" so browsers can fill them in.

Legal Requirements for WordPress Accessibility

Accessibility law has moved from "best practice" to enforceable deadlines in the US and the EU. The technical bar in nearly every case is WCAG at Level AA, which is why the WordPress work above maps directly to legal exposure.

United States: ADA Title II

The Department of Justice published its ADA Title II web rule on April 24, 2024. It covers state and local governments, including cities, counties, school districts, public universities, and special districts, and it sets WCAG 2.1 Level AA as the standard for websites, mobile apps, and the documents posted on them. An interim final rule in April 2026 pushed both compliance dates back one year:

Nothing else in the rule changed, so the extra year is time to remediate, not a reason to wait. Our ADA website deadline guide covers the timeline, and what the ADA web rule requires of city websites walks through scope, exceptions, and PDFs.

United States: ADA Title III

Private businesses fall under Title III, which still has no DOJ technical standard for websites. Courts and settlement agreements consistently use WCAG 2.1 or 2.2 Level AA as the benchmark, and demand letters and lawsuits keep coming, with ecommerce and hospitality sites hit most often. If a letter has already arrived, read what to do after a website accessibility lawsuit before you reply.

European Union: European Accessibility Act

The European Accessibility Act has applied since June 28, 2025. It covers many consumer-facing digital services sold in the EU, including ecommerce, banking, and transport booking, regardless of where the business is based. The harmonised standard behind it, EN 301 549, references WCAG 2.1 Level AA for web content.

Why Target WCAG 2.2 AA

Every law above names WCAG 2.1 AA today, but WCAG 2.2 is the current W3C Recommendation and it builds on 2.1. A site that meets 2.2 AA also meets 2.1 AA, and the new criteria (target size, focus not obscured, accessible authentication, consistent help) fix real problems users report. Building to 2.2 now means you won't redo the work when regulations catch up.

Overlays Don't Make a Site Compliant

Accessibility overlay plugins promise compliance with one line of JavaScript. They don't deliver it. In 2025 the FTC issued a final order against accessiBe, including a $1 million payment, over claims that its tool could make any website WCAG compliant. Overlays can't fix missing form labels, broken heading structure, keyboard traps, or inaccessible PDFs, and some interfere with the screen readers users already rely on. Our breakdown of why an accessibility overlay is not WCAG compliance covers the details.

Keeping a WordPress Site Accessible Over Time

Accessibility is a property of the live site, and the live site changes every week. A theme update can strip focus styles, a new plugin can add an unlabeled form, and an editor can upload a hero image with no alt text. A one-time audit decays unless you keep testing.

Automate the Checks You Can

Automated tools catch the mechanical failures: missing alt attributes, empty links, low contrast, missing form labels. Run them on a schedule and after every deployment. Pa11y CI can crawl your sitemap from a pipeline or a cron job:

npx pa11y-ci --sitemap https://example.com/sitemap.xml

Pair this with the visual regression and deployment checks in our CI/CD pipeline guide so accessibility regressions fail a build instead of reaching visitors. For a comparison of scanners, see our WordPress accessibility testing tools roundup.

Test Manually Where Automation Can't

Automated scanners only find part of the problems that matter. They can't judge whether alt text describes the image, whether focus order makes sense, or whether a screen reader user can finish your checkout. Schedule a manual pass with a keyboard and NVDA or VoiceOver on your key templates (home page, a standard page, a post, a form, and checkout if you have one) at least once a quarter and after any redesign.

Train Content Editors

Most new accessibility issues on established sites come from content, not code. Give editors a short checklist: write meaningful alt text, use headings in order, use descriptive link text, don't convey meaning with color alone, and add captions to video. Uploaded PDFs need the same attention as pages; government sites should fix PDFs first because they are often the largest backlog.

Publish an Accessibility Statement

An accessibility statement tells visitors which standard you target, any known gaps, and how to report a problem. It is required for public sector sites in the EU and a good-faith signal everywhere else. Make the contact method itself accessible: an email address or phone number, not only a form.

TopSyde's managed WordPress hosting starts at $89/month per site and includes staging environments for testing theme and plugin updates before they reach production. For public agencies and businesses facing ADA deadlines, our ADA compliance service adds scanning, remediation, and ongoing monitoring.

Frequently Asked Questions

Is WordPress accessible out of the box?

WordPress core is built to WCAG standards, and the admin and block editor are tested with screen readers and keyboards. Your site's accessibility depends on everything layered on top: the theme, the plugins, and the content your team publishes. A core install with an accessibility-ready theme is a strong starting point, but a page builder, slider, or form plugin can undo that in one update, so test the whole site after every major change.

How many success criteria does WCAG 2.2 Level AA include?

WCAG 2.2 has 55 success criteria at Levels A and AA combined, which is what Level AA conformance requires. WCAG 2.2 added nine new criteria to WCAG 2.1 (six of them at Level A or AA) and removed 4.1.1 Parsing, which is now obsolete. The remaining criteria are Level AAA, which few laws require for whole sites.

Do accessibility overlay plugins make a WordPress site ADA compliant?

No. Overlays add a toolbar and attempt automated fixes in the browser, but they can't repair the underlying markup problems that WCAG tests for, and lawsuits have been filed against sites that used them. The FTC's 2025 order against accessiBe, including a $1 million payment, came from claims that its overlay made sites compliant. Fix the theme, plugins, and content directly instead.

When do government WordPress sites need to meet the ADA Title II rule?

State and local governments with a population of 50,000 or more must meet WCAG 2.1 Level AA by April 26, 2027. Entities with populations under 50,000 and special districts have until April 26, 2028. Both dates were moved back one year by an interim final rule in April 2026, and the technical standard did not change.

Can automated testing tools confirm my site is compliant?

No single tool can. Automated scanners like axe, WAVE, Lighthouse, and Pa11y reliably catch mechanical issues such as missing labels and contrast failures, but many criteria need human judgment: meaningful alt text, logical focus order, understandable error messages, and whether a task can be completed with a screen reader. Use automated scans for coverage and regression alerts, and manual keyboard and screen reader testing for conformance.

How often should I audit WordPress accessibility?

Run automated scans on every deployment or at least weekly, do a manual keyboard and screen reader pass on key templates quarterly, and run a full audit after a redesign, a theme change, or the addition of a major plugin such as a page builder or form tool. Sites that publish a lot of content should also spot-check new pages and PDFs monthly.

Keep Reading on TopSyde

• WordPress Custom Post Types and Taxonomies Explained. Complete guide to WordPress custom post types: registration, taxonomies, ACF integration, REST API exposure, and query optimization for developers.
• WordPress Error Debugging: White Screen, 500 Errors, and More. Learn to debug WordPress errors systematically: enable WP_DEBUG, isolate plugin conflicts, fix WSOD and 500 errors with professional techniques.
• WordPress Page Builders Compared: Elementor, Bricks, Breakdance. Compare WordPress page builders on performance, developer flexibility, and maintainability. Expert analysis of Elementor, Bricks, Breakdance, and Gutenberg.
• TopSyde SLA & uptime guarantee
• Performance spec sheet

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.

LinkedIn