How to Make a WordPress Website Accessible for WCAG Compliance?

Try using your own WordPress site with only a keyboard. Press Tab from the top of the home page and watch where the focus goes. On many sites it disappears after the first link, gets trapped in a slider, or takes forty presses to reach the main content. Now imagine reading the same page with a screen reader that announces every image as "image" and every button as "button". That is how a large share of visitors experience the web, and it is why accessibility is now both a usability issue and, for many organizations, a legal one.

WordPress gives you a strong starting point. Core's admin and default themes are built to accessibility standards, and the block editor produces mostly semantic HTML. But accessibility is decided by the whole site: your theme, your plugins, your colors, and every piece of content your editors publish.

This article covers what WCAG 2.2 Level AA requires in practice, how to choose an accessible theme, how to fix the most common problems in WordPress (color contrast, keyboard focus, skip links, headings, images, links, forms, and motion), what to watch for with plugins and page builders, how to test your site, and how laws such as the European Accessibility Act and the ADA relate to WCAG.

What WCAG Compliance Means

The Web Content Accessibility Guidelines (WCAG), published by the W3C, are the standard that most laws and policies refer to. WCAG is organized around four principles: content must be perceivable, operable, understandable, and robust. Each principle has testable success criteria at three levels: A, AA, and AAA.

Level AA is the usual target. It includes all Level A criteria plus the AA ones, and it is the level referenced by most regulations.

WCAG 2.2, published in October 2023, is the current version. It keeps nearly everything from WCAG 2.1 and adds new criteria. The ones at Level A and AA most relevant to WordPress sites are:

WCAG 2.2 criterion	Level	What it means for a WordPress site
2.4.11 Focus Not Obscured (Minimum)	AA	Sticky headers, cookie banners, and chat widgets must not hide the focused element
2.5.7 Dragging Movements	AA	Sliders and drag-to-reorder features need a non-dragging alternative
2.5.8 Target Size (Minimum)	AA	Buttons and links need a target of at least 24 by 24 CSS pixels, or enough spacing
3.2.6 Consistent Help	A	Help links or contact details appear in the same place on every page
3.3.7 Redundant Entry	A	Forms do not make users re-type information they already gave
3.3.8 Accessible Authentication (Minimum)	AA	Logins do not rely on memory puzzles; allow password managers and pasting

WCAG 2.2 also removed criterion 4.1.1 Parsing, which no longer applies.

Compliance is not a badge you install. It means every page and every template meets each applicable criterion, and it is maintained as content changes.

Step 1: Start with an Accessible Theme

The theme controls most of the markup visitors interact with: the header, navigation, landmarks, focus styles, and colors. A theme with accessibility problems will undo most of the work you do elsewhere.

When choosing a theme:

1. In the WordPress.org theme directory, use the Feature Filter and select the Accessibility Ready tag. Themes with this tag have been reviewed against a set of accessibility requirements, including keyboard navigation, skip links, focus styles, contrast, and heading structure.
2. Prefer modern block themes such as the current default theme. They use semantic landmarks and core blocks.
3. Test the demo with a keyboard before committing: Tab through the menu, open submenus, and check that focus is always visible.

The Accessibility Ready tag is a good baseline, not a guarantee of WCAG conformance. You will still need to check your own customizations and content.

Step 2: Fix Color Contrast

Low contrast is one of the most common accessibility failures on the web. WCAG 2.2 AA requires:

• 4.5:1 contrast for normal body text against its background
• 3:1 for large text, meaning at least 24px regular or about 18.7px bold
• 3:1 for user interface components and graphics needed to understand content, such as input borders, icons, and focus indicators

In a block theme, set the palette in Appearance → Editor → Styles → Colors, or in theme.json, so every block uses compliant combinations by default:

// theme.json (excerpt)
{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "base", "color": "#ffffff", "name": "Base" },
        { "slug": "contrast", "color": "#1a1a1a", "name": "Contrast" },
        { "slug": "accent", "color": "#0b57d0", "name": "Accent" },
        { "slug": "muted", "color": "#595959", "name": "Muted" }
      ],
      "custom": false,
      "customGradient": false
    }
  }
}

Setting custom to false removes the free-form color picker in the editor, so editors can only choose from the tested palette. The block editor also shows a contrast warning in the block sidebar when a text and background combination is too low.

Check every combination you actually use, including button text on button backgrounds, link colors in body text, and placeholder text. The ratios, measurement tools, and exceptions are explained in what the WCAG contrast requirements for text are.

Step 3: Make Keyboard Focus Visible

Keyboard users, and many screen reader and switch users, navigate with Tab and Shift+Tab. They need to see where focus is at all times. Many themes remove the browser's focus outline because a designer thought it looked untidy, which makes the site unusable without a mouse.

Add a clear focus style that meets the 3:1 contrast requirement for UI components:

/* style.css or Appearance → Editor → Styles → Additional CSS */
:where(a, button, input, select, textarea, summary, [tabindex]):focus-visible {
  outline: 3px solid #0b57d0;
  outline-offset: 2px;
  border-radius: 2px;
}

/* Never remove focus without a replacement */
:focus:not(:focus-visible) {
  outline: none;
}

The :focus-visible pseudo-class shows the outline for keyboard navigation but not after mouse clicks, which satisfies both users and designers.

For WCAG 2.2's Focus Not Obscured criterion, make sure sticky headers, cookie banners, and chat buttons do not cover the element in focus. If your theme uses a sticky header, scroll-padding-top keeps focused elements clear of it:

/* style.css */
html {
  scroll-padding-top: 6rem; /* roughly the height of the sticky header */
}

Step 4: Provide a Skip Link and Landmarks

A skip link is the first focusable element on the page and jumps straight to the main content, so keyboard users do not have to Tab through the whole menu on every page.

Block themes: WordPress automatically adds a skip link to block themes, as long as the template contains a main element. In the Site Editor, select the Group block that wraps your content, open Advanced, and set HTML element to main. In template HTML, it looks like this:

<!-- templates/single.html (excerpt) -->
<!-- wp:group {"tagName":"main","layout":{"type":"constrained"}} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

Classic themes: add the link yourself as the first element inside body, using the core screen-reader-text pattern that becomes visible on focus:

<?php // header.php (excerpt) ?>
<body <?php body_class(); ?>>
<?php wp_body_open(); ?>
<a class="skip-link screen-reader-text" href="#primary"><?php esc_html_e( 'Skip to content', 'your-textdomain' ); ?></a>

/* style.css */
.screen-reader-text {
  border: 0;
  clip-path: inset(50%);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
  word-wrap: normal !important;
}

.skip-link.screen-reader-text:focus {
  clip-path: none;
  height: auto;
  width: auto;
  top: 0.5rem;
  left: 0.5rem;
  z-index: 100000;
  padding: 0.75rem 1rem;
  background: #ffffff;
  color: #1a1a1a;
}

Make sure the target ID, here #primary, exists on the element that wraps your main content. Also check that the theme uses landmarks: header, nav, main, and footer. Screen reader users jump between them the same way sighted users scan a page.

Step 5: Structure Content with Proper Headings

Screen reader users often navigate by headings, listing them all and jumping to the section they want. That only works if headings reflect the real structure of the page.

• Use one H1 per page, normally the post or page title, which the theme outputs.
• Start content headings at H2, and do not skip levels when going deeper. An H4 should follow an H3, not an H2.
• Never pick a heading level for its font size. Change the size in the block's typography settings instead.
• Do not use bold paragraphs as fake headings. They are invisible to heading navigation.

The block editor helps here. Open the Document Overview panel (the list icon in the top toolbar) and switch to the Outline tab, which shows your heading hierarchy and flags skipped levels.

Step 6: Write Useful Alternative Text

Every meaningful image needs alt text that conveys what the image communicates in context. In WordPress, set it in the Image block's sidebar under Alternative text, or in the Media Library.

• Informative images: describe the content and purpose, for example "Bar chart showing sales doubling from January to June".
• Functional images, such as a linked logo: describe the destination, for example "Example Store home".
• Decorative images: leave the Alternative text field empty. WordPress then outputs an empty alt attribute, which tells screen readers to skip the image.
• Images of text: avoid them. If you must use one, include the full text in the alt.

WordPress outputs whatever is in the alt field when it renders images, so the work is in the content, not the code. More examples and edge cases are in the importance of alt text in WordPress images.

Step 7: Make Links and Buttons Clear

• Write descriptive link text. "Read more" and "Click here" mean nothing when a screen reader lists all links on a page. Use text such as "Read the shipping policy".
• Distinguish links from text by more than color. Underline links in body content. Color alone fails users who cannot perceive the difference.
• Use buttons for actions and links for navigation. A Button block is styled as a button but renders as a link, which is correct only when it navigates somewhere.
• Warn when a link opens a new tab. If you set a link to open in a new tab, say so in the link text, for example "Pricing guide (opens in a new tab)".
• Meet the target size. WCAG 2.2's 24 by 24 pixel minimum mostly affects icon buttons, social icons, and tightly packed footer links. Add padding if they are too small.

/* style.css */
.entry-content a:not(.wp-element-button) {
  text-decoration: underline;
  text-underline-offset: 0.15em;
}

.wp-block-social-links .wp-social-link a {
  min-width: 24px;
  min-height: 24px;
}

Step 8: Build Accessible Forms

Forms are where accessibility failures cost conversions directly. Contact forms, checkout, login, and newsletter sign-ups all need:

• A visible label for every field. Placeholder text is not a label: it disappears as soon as the user types and often has low contrast.
• Programmatic labels, so each label is linked to its input with a matching for and id.
• Clear error messages that say what went wrong and how to fix it, placed next to the field and announced to screen readers.
• Grouped related fields, such as radio buttons, inside a fieldset with a legend.
• Autocomplete attributes for personal data, such as autocomplete="email", which helps everyone and supports WCAG's input purpose criterion.

Accessible markup looks like this:

<!-- Accessible form field pattern -->
<label for="contact-email">Email address (required)</label>
<input
  id="contact-email"
  name="email"
  type="email"
  autocomplete="email"
  required
  aria-describedby="contact-email-error"
/>
<p id="contact-email-error" class="field-error" role="alert" hidden>
  Enter an email address in the format name@example.com.
</p>

Most form plugins generate this kind of markup when configured properly. Turn on visible labels, avoid placeholder-only designs, and test the error state with a keyboard and screen reader. Avoid CAPTCHAs that require solving visual puzzles, which conflicts with WCAG 2.2's accessible authentication criterion.

Step 9: Respect Motion and Media Preferences

• Avoid autoplaying carousels. If a slider auto-advances, it needs a pause button. Many accessibility specialists recommend avoiding carousels for important content entirely.
• Respect reduced motion. Some users get dizzy or nauseous from animation. Turn off non-essential animation when they ask for it:

/* style.css */
@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;
  }
}

• Caption videos and provide transcripts for audio. The Video block supports caption tracks, and most video platforms generate captions you can edit.
• Never autoplay audio.

Use ARIA Sparingly

ARIA attributes can add meaning that HTML lacks, but the first rule of ARIA is to prefer native HTML elements. A button element is already focusable, clickable with Enter and Space, and announced as a button. A div with role="button" needs all of that rebuilt by hand. Incorrect ARIA is worse than none, because it tells assistive technology something untrue. Use ARIA only for patterns HTML cannot express, such as aria-expanded on a menu toggle or aria-current="page" on the active navigation link, which core navigation blocks already output.

Plugins, Page Builders, and Overlays

Every plugin that outputs front-end markup affects accessibility: sliders, pop-ups, mega menus, cookie banners, and form builders are the usual offenders. Before installing one, check its documentation for accessibility notes and test its output with a keyboard.

Page builders vary widely. Some output deeply nested markup with generic elements, which makes heading structure and landmarks harder to control. If you use one, check heading levels, button semantics, and focus order on each template.

Be cautious with accessibility overlay widgets that promise one-line compliance. They do not fix underlying markup, accessibility practitioners widely criticize them, and they do not make a site WCAG conformant on their own. Fix the site itself instead.

Testing Your WordPress Site

Automated tools catch only part of WCAG issues, commonly estimated at around a third. Use them as a first pass, then test manually.

Automated testing

• axe DevTools browser extension: run it on each template type (home, post, page, archive, search, contact, checkout).
• WAVE from WebAIM: shows errors visually on the page, useful for content editors.
• Lighthouse in Chrome DevTools: includes an accessibility audit based on axe rules.

Manual testing

1. Keyboard only. Unplug the mouse. Tab through every template. Can you reach and operate everything? Is focus always visible? Does the skip link work? Can you close menus and dialogs with Escape?
2. Zoom to 200% and 400%. Text must stay readable without horizontal scrolling at 320 CSS pixels wide.
3. Screen reader. Use NVDA on Windows (free) or VoiceOver on macOS and iOS (built in). Listen to the headings list, links list, form labels, and error messages.
4. Content review. Check alt text, link text, and heading order on your most visited pages.

Test after theme updates, major plugin updates, and redesigns, not just once. Accessible typography choices are covered separately in how to make website typography accessible.

Accessibility Laws and WCAG

Accessibility requirements depend on where you operate and what you do, so treat this as background and get legal advice for your specific situation.

• European Union: The European Accessibility Act has applied since 28 June 2025 to many products and services sold to consumers in the EU, including e-commerce, banking, transport, and e-books. Its technical requirements point to the harmonized standard EN 301 549, which incorporates WCAG 2.1 Level AA for web content. Microenterprises providing services have an exemption.
• United States: The ADA applies to businesses open to the public, and US courts have heard many website accessibility lawsuits. The Department of Justice's 2024 rule for state and local governments under Title II references WCAG 2.1 Level AA.
• Other regions: Many countries reference WCAG in public sector or broader rules, such as the UK's public sector accessibility regulations and Canada's accessibility laws.

Because WCAG 2.2 builds on 2.1, targeting WCAG 2.2 AA covers the 2.1 requirements these laws reference. An accessibility statement page describing your conformance target, known issues, and a contact method is required in some cases and good practice everywhere.

Common Problems and Fixes

• Focus disappears on menus or buttons. The theme removed the outline with outline: none. Add a :focus-visible style with at least 3:1 contrast.
• The skip link does not appear in a block theme. The template has no main element. Set the content Group block's HTML element to main.
• Contrast warnings on buttons. The theme's accent color is too light for white text. Darken the accent in the palette rather than overriding it block by block.
• Screen readers announce "image" or a file name. Alt text is missing. Fill in the Alternative text field, or leave it empty only if the image is purely decorative.
• Submenus cannot be opened with a keyboard. The menu relies on hover. Switch to the core Navigation block or a menu plugin with keyboard support.
• Cookie banner traps focus or hides content. Choose a consent tool that can be dismissed with a keyboard and does not cover focused elements.
• Automated tools pass, but users still report problems. Automated tests miss many issues. Do keyboard and screen reader testing on real templates.

WordPress Accessibility FAQ

Conclusion

An accessible WordPress site is built in layers. Start with a theme that has a solid foundation, such as one tagged Accessibility Ready. Lock in a compliant color palette, restore visible keyboard focus, and make sure every template has a skip link and proper landmarks. Then make accessibility part of content work: real headings in order, meaningful alt text, descriptive links, and forms with visible labels and clear errors.

Test the way your visitors browse, with a keyboard and a screen reader as well as automated tools, and repeat after every major update. WCAG 2.2 Level AA is a demanding but achievable target, and meeting it makes your site easier for everyone to use, not only for people with disabilities.

Here are some useful references for going deeper on WordPress accessibility:

1. W3C: Web Content Accessibility Guidelines (WCAG) 2.2 — the full standard and every success criterion.
2. W3C WAI: What's New in WCAG 2.2 — the new criteria explained with examples.
3. WordPress.org: Accessibility Handbook — WordPress accessibility guidance for themes, plugins, and content.
4. WordPress.org: Accessibility Ready theme requirements — what the Accessibility Ready tag checks.
5. WebAIM: WAVE Web Accessibility Evaluation Tools — free tools for checking pages for accessibility errors.