Boost WordPress Accessibility: Essential WCAG 2.2 Guide

Over 1.3 billion people worldwide live with some form of disability. Many of them visit WordPress sites every day using screen readers, keyboard-only navigation, or high-contrast display settings. If your site does not accommodate these users, you are not just missing a portion of your audience. In some countries, you may also be exposing yourself to legal risk. WCAG 2.2 is the current international standard for web accessibility, and hitting AA compliance is achievable for any WordPress site owner who follows the right steps.

This guide covers every practical checkpoint you need to reach WCAG 2.2 AA compliance in 2026: semantic HTML landmarks, heading order, alt text, focus states, color contrast ratios, skip links, form labels, ARIA usage, keyboard navigation, and reduced motion. You will also find tool recommendations and WordPress-specific plugin guidance throughout.

What WCAG 2.2 AA Actually Requires (The Short Version)

WCAG stands for Web Content Accessibility Guidelines. The 2.2 version, published in October 2023, introduced nine new success criteria on top of the WCAG 2.1 baseline. For most sites, AA compliance is the legal target. AAA is aspirational and often impractical for general content.

The four core principles are:

• Perceivable: Content must be presentable in ways users can perceive (text alternatives, captions, adaptable layouts, sufficient contrast).
• Operable: Interface components must be operable by keyboard and other input methods.
• Understandable: Content and UI must be understandable (consistent navigation, error identification, labels).
• Parseable by assistive tech: Content must be well-formed and correctly structured so screen readers and other tools can interpret it reliably.

WCAG 2.2 added new criteria including minimum target sizes for interactive controls (2.5.8, at least 24×24 CSS pixels), focus appearance requirements (2.4.11), and removed the AAA-only “Parsing” criterion. If you were already at WCAG 2.1 AA, the delta is not huge, but the focus and target size criteria affect most WordPress themes.

Start With Semantic HTML Landmarks

Screen readers use HTML landmark elements to help users jump directly to sections of a page. Without them, users hear a wall of content and have to listen through every navigation link to get to the main text.

The key landmarks are:

• <header> or role="banner" for your site header
• <nav> or role="navigation" for navigation menus
• <main> or role="main" for the primary content area
• <footer> or role="contentinfo" for the site footer
• <aside> or role="complementary" for sidebars

Most modern WordPress themes built after 2020 include these correctly. But page builders like Elementor sometimes wrap everything in generic <div> elements. To check your own site, open the browser DevTools, inspect the page, and look for <main>, <nav>, and <header> tags. If they are missing, you can add landmark roles using the ARIA Landmark Roles plugin or by editing your theme’s header.php and footer.php files.

If you have multiple navigation blocks on a page (primary nav, footer nav, breadcrumbs), each <nav> element should have a unique aria-label attribute so screen reader users can distinguish them:

<nav aria-label="Primary navigation">...</nav>
<nav aria-label="Footer links">...</nav>

Fix Your Heading Order (It Matters More Than You Think)

Headings are not just visual style choices. Screen reader users frequently navigate pages by jumping between headings using keyboard shortcuts. An H1 jumping to H4 with no H2 or H3 in between breaks that navigation flow completely.

The rules are simple:

• Each page should have exactly one H1 (your theme renders the post title as H1 automatically in WordPress, so your content body should never start with an H1 tag).
• H2 introduces main sections. H3 introduces subsections of H2. Do not skip levels.
• Do not choose heading levels based on their visual size. Change the CSS if you want a heading to look smaller. Do not use an H4 just because it renders at the size you want.

The Gutenberg block editor enforces this fairly well when you use the Heading block and pay attention to the level dropdown. The Accessibility Checker plugin by Equalize Digital will flag heading order violations directly inside your WP admin.

Alt Text: The Right Way to Write It

Every image that conveys information needs descriptive alt text. Decorative images (dividers, background textures, icons that duplicate adjacent text) should have empty alt attributes (alt="") so screen readers skip them. The mistake most site owners make is treating both cases the same.

Tips for writing useful alt text:

• Describe what the image shows, not what the image “is.” Instead of “Image of a bar chart,” write “Bar chart showing plugin download growth from 2022 to 2026, peaking in Q3 2025.”
• Do not start with “Image of” or “Photo of.” Screen readers already announce it as an image.
• Keep it under 150 characters. If you need more context, use a caption or a visible description below the image.
• For complex images like infographics, link to a longer text description or provide it in surrounding content.

WordPress stores alt text per media item in the Media Library. You can bulk-update missing alt text using the WP Accessibility Helper plugin, or use the “Accessibility” tab in the block editor’s image settings for per-post overrides.

Images also play a big role in page performance, which overlaps with accessibility. Users on slow connections or older devices are more likely to be using assistive technologies. Optimizing your images helps everyone. See the guide on how to compress WordPress images for faster pages for the complete process.

Color Contrast: Hitting the 4.5:1 Ratio

WCAG 2.2 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18px bold or 24px regular). The requirement also applies to user interface components and graphical elements under WCAG 1.4.11.

The most common failures on WordPress sites:

• Light gray text on white backgrounds (a favorite of minimal theme designers)
• Placeholder text in form inputs (often set to something like #aaa on #fff, which fails)
• Colored buttons with insufficient text contrast
• Focus outlines that disappear on colored backgrounds

To check contrast ratios, use the WebAIM Contrast Checker. Enter your text hex color and background hex color and it tells you instantly whether you pass or fail for normal text, large text, and UI components. The browser DevTools also now include a built-in contrast ratio checker in the Accessibility tab when you inspect any element.

For your WordPress theme, contrast fixes usually live in the Customizer under Colors, or in the Additional CSS section. If you are using a block theme, the theme.json file controls the color palette. Make sure every palette color you use for text passes against its intended background.

Focus States and Keyboard Navigation

Every interactive element on your page, including links, buttons, form fields, and custom widgets, must have a visible focus indicator when navigated by keyboard. WCAG 2.4.11 (new in 2.2) requires that the focus indicator not be entirely hidden by the author, and 2.4.12 adds minimum size and contrast requirements at AAA level.

The single worst thing a theme can do is this CSS:

*:focus { outline: none; }

That one line removes all focus indicators from every element, making keyboard navigation impossible to follow visually. Search your theme’s CSS for outline: none or outline: 0 and remove those rules, or replace them with a properly styled focus ring:

*:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

Using :focus-visible instead of :focus is a modern best practice. It shows the focus ring for keyboard users but suppresses it for mouse clicks, so your design looks clean for pointer users while remaining accessible for keyboard users.

To test keyboard navigation on your own site, close your mouse and use only Tab, Shift+Tab, Enter, Space, and arrow keys. You should be able to reach every link, button, and form field. If you ever get “stuck” with no visible focus indicator, that is a failure.

Skip Links: The First Thing on Every Page

A skip link is a visually hidden (but keyboard-accessible) link at the very top of the page that lets keyboard users skip past the navigation to the main content. Without it, a user tabbing through your site must press Tab dozens of times to get past your header and navigation on every single page they visit.

Adding a skip link to WordPress is straightforward. Open your header.php file (or use the Code Editor in a block theme) and add this as the very first item inside the <body> tag:

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

Then make sure your main content area has id="main":

<main id="main">

The CSS for the skip link keeps it invisible until focused:

.skip-link.screen-reader-text {
  position: absolute;
  left: -9999px;
}
.skip-link.screen-reader-text:focus {
  left: 6px;
  top: 6px;
  z-index: 99999;
  padding: 8px 16px;
  background: #000;
  color: #fff;
  font-size: 1rem;
}

Most well-maintained WordPress themes (Twenty Twenty-Three, Astra, GeneratePress) already include this. Check by pressing Tab on your homepage with no previous focus. If the first thing you see is a “Skip to content” link appearing at the top, you are good.

Form Labels and Error Messages

Forms are where most accessibility failures concentrate on WordPress sites. Contact forms, comment forms, WooCommerce checkout, subscription forms, all of them need explicit, programmatic labels for every input field.

The requirement is that each form input has a <label> element with a for attribute matching the input’s id:

<label for="user-email">Email address</label>
<input type="email" id="user-email" name="email">

Placeholder text does not count as a label. Once a user starts typing, the placeholder disappears, and screen readers do not reliably announce placeholders as labels anyway.

For error messages, WCAG 3.3.1 requires that errors be identified in text (not just by color), and 3.3.3 requires suggestions for correction where possible. A good error pattern is:

<p role="alert" id="email-error">Please enter a valid email address.</p>
<input type="email" aria-describedby="email-error" aria-invalid="true">

The role="alert" causes screen readers to announce the error immediately. The aria-describedby links the error message to the input, and aria-invalid="true" signals the error state.

For WooCommerce and Contact Form 7, the accessibility of your forms depends partly on the plugin and partly on your theme. Contact Form 7 generates accessible markup by default. WooCommerce checkout has had ongoing accessibility improvements. If you are building forms yourself, WP Accessible Forms or simply building on top of the block-based Form block can help.

If you are using a contact form plugin that generates its own markup, check the guide on creating a WordPress contact form for alternative approaches that give you more markup control.

ARIA: Only When You Actually Need It

ARIA (Accessible Rich Internet Applications) attributes let you add accessibility semantics to HTML elements that do not have them by default. Developers tend to overuse ARIA, which creates more problems than it solves. The first rule of ARIA is: do not use ARIA if a native HTML element does the job.

Use ARIA when you are building custom widgets that have no native HTML equivalent: accordions, tab panels, modal dialogs, custom dropdown menus, carousels. For everything else, use semantic HTML.

Common ARIA patterns you will actually use in WordPress:

• aria-label on icon-only buttons: <button aria-label="Close menu"><svg>...</svg></button>
• aria-expanded on toggle buttons: changes between true and false when a menu or accordion opens and closes
• aria-hidden="true" on purely decorative icons or images you want screen readers to skip
• aria-live="polite" on regions that update dynamically (search results, cart totals) so screen readers announce the change

Avoid stacking ARIA roles on top of native HTML elements. <button role="button"> is redundant. <div role="button"> is a red flag. Use <button> and get the semantics for free.

Reduced Motion: Respecting User Preferences

WCAG 2.3.3 (AAA) and increasingly common best practice recommend respecting the prefers-reduced-motion media query. Users with vestibular disorders, migraines, or seizure sensitivity can set a system preference to reduce motion. If your site has parallax scrolling, spinning loaders, automatic carousels, or animated page transitions, you need to honor this preference.

The CSS is minimal:

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Add this to your theme’s CSS. For WordPress themes using JavaScript-driven animations (Elementor scroll effects, GSAP integrations, WP-Anime), you also need to check the animation setting in the page builder and disable autoplay where possible. Many modern page builders check prefers-reduced-motion in their JavaScript now, but verify rather than assume.

Tools to Test Your Site

Testing accessibility is not optional. Your own code review will miss things. Use at least two automated tools and at least one manual test.

Automated Tools

axe DevTools (browser extension by Deque): The most widely used accessibility linter. Install the Chrome or Firefox extension, open DevTools, go to the axe tab, and run a scan. It categorizes issues by impact (critical, serious, moderate, minor) and links every finding to the WCAG criterion it violates. The free tier covers the most common failures. axe finds about 30-40% of WCAG issues automatically.

Google Lighthouse (built into Chrome DevTools): Open DevTools, go to the Lighthouse tab, check Accessibility, and run the audit. It uses axe under the hood for most checks but also includes additional checks from the Chrome accessibility tree. It gives a score out of 100 and a checklist of items to fix.

WAVE (wave.webaim.org or browser extension by WebAIM): WAVE overlays visual indicators directly on the page, showing where alt text is missing, where contrast fails, where ARIA errors appear, and where heading structure breaks down. It is particularly good for visual learners because you see the issue in context.

Manual Testing

Keyboard-only navigation: Close your mouse. Tab through every page. Every interactive element must be reachable and usable. You should never lose track of where focus is.

NVDA (Windows) or VoiceOver (macOS/iOS): NVDA is a free screen reader for Windows. VoiceOver is built into macOS and iOS. Turn on VoiceOver (Command + F5 on Mac) and navigate your site. Listen to how your content is announced. Pay attention to the order of reading, the labels on buttons and links, and whether dynamic content updates are announced.

Browser zoom to 200%: WCAG 1.4.4 requires that text can be resized to 200% without loss of content or functionality. Zoom in and check that no text is cut off, no buttons become unreachable, and no overlapping occurs.

WordPress Plugins and Themes That Help

The right tooling makes WCAG compliance significantly easier to maintain, especially across a site with many contributors.

Recommended Accessibility Plugins

• Accessibility Checker by Equalize Digital: Scans your content directly in the WP editor and flags issues before you publish. Free version covers the most important checks. Pro version adds more detailed reporting and front-end scanning.
• WP Accessibility by Joe Dolson: A utility plugin that fixes common theme-level issues: adds skip links if they are missing, adds lang attributes, fixes the admin toolbar for screen reader users, and adds keyboard focus styling. It is not a replacement for fixing your theme, but it patches gaps quickly.
• One Click Accessibility: Adds a toolbar overlay to your site with font size controls, contrast toggles, and focus highlighting. Useful for users who want to customize their experience on your site.

Theme Considerations

If you are choosing a new WordPress theme and accessibility is a priority, look for themes that carry the WordPress.org accessibility-ready tag. This does not mean full WCAG compliance, but it does mean the theme has passed a baseline review by the WordPress accessibility team: skip links present, proper heading hierarchy, keyboard navigable, sufficient contrast in the default color scheme.

Astra, GeneratePress, Neve, and Kadence are all popular themes with strong accessibility foundations. Block themes built on WordPress’s own Twenty Twenty-Four or Twenty Twenty-Five frameworks score well by default.

Page builders (Elementor, Divi, Beaver Builder) can produce accessible markup, but only if you use them carefully. Elementor has accessibility settings per widget, including aria-labels and keyboard navigation options. Enable these explicitly. Do not rely on defaults.

Building an Ongoing Accessibility Process

A one-time audit is not enough. Every new page, plugin, or theme update can introduce new accessibility issues. Build accessibility into your publishing workflow:

• Run the Accessibility Checker plugin scan before publishing every new post or page.
• Set a quarterly reminder to run a Lighthouse accessibility audit on your homepage, contact page, and most-visited pages.
• When evaluating new plugins, check whether they include any front-end output and test that output with axe before activating on production.
• If you have guest authors or a team of editors, include a one-page accessibility checklist in your editorial guide: alt text for every informational image, no heading levels skipped, descriptive link text (no “click here” or “read more”).

Accessibility improvements tend to benefit everyone. Better heading structure helps your SEO, because search engines use heading hierarchy to understand content structure. Better color contrast is easier to read in bright sunlight. Better keyboard navigation helps power users who prefer not to use a mouse. The overlap between accessibility, performance, and SEO is substantial. A fast, accessible, well-structured WordPress site is a better site for every visitor.

If you are also thinking about performance improvements alongside accessibility, the guide on how to speed up your WordPress site covers the technical optimizations that help the same users who rely on assistive technology.

Quick WCAG 2.2 AA Compliance Checklist

Use this as your final review before claiming compliance:

• All pages have semantic landmark elements: <header>, <nav>, <main>, <footer>
• One H1 per page, no skipped heading levels
• All informational images have descriptive alt text; decorative images have alt=""
• Normal text meets 4.5:1 contrast ratio; large text meets 3:1
• UI components (form fields, buttons, icons) meet 3:1 contrast against adjacent color
• Skip link is the first focusable element on every page
• All focus states are visible and not suppressed with outline: none
• Interactive elements have a minimum target size of 24×24 CSS pixels (WCAG 2.5.8)
• Every form input has an explicit <label>; placeholder text is not used as the sole label
• Error messages are conveyed in text, not color alone
• All video content has captions; audio has transcripts
• Page language is set (<html lang="en">)
• prefers-reduced-motion is respected for animations
• Site is fully keyboard-navigable with no focus traps
• Automated scans with axe and Lighthouse return zero critical/serious issues

WCAG 2.2 AA compliance is a practical goal for any WordPress site. The tools exist, the plugins help, and most of the work is about building good habits rather than heroic technical effort. Start with a Lighthouse scan today, fix the critical issues first, and work through the list systematically. Your entire audience, including the one in ten visitors who uses some form of assistive technology, will have a meaningfully better experience on your site.

Beginner WordPress Tips Keyboard Navigation Screen Readers WCAG 2.2 WordPress Accessibility

Last modified: May 8, 2026