WordPress Accessibility: How to Make Your Site WCAG Compliant

WordPress accessibility is mostly about avoiding self-inflicted wounds

Accessibility on WordPress is mostly about not shooting yourself in the foot. The platform itself is genuinely accessible out of the box, thanks to years of work by the WordPress accessibility team. What breaks accessibility on a real client site is almost always the themes, page builders, and custom blocks layered on top. They break keyboard navigation, strip contrast, and bury form labels inside placeholder text that screen readers cannot find.

This guide is the short path to WCAG 2.2 Level AA on a real WordPress site. Not a philosophy essay, not a compliance-theatre checklist. Just what works, in the order you should do it, based on what I have audited and fixed on client sites over the last three years.

The standard to aim for is WCAG 2.2 Level AA. That is what the European Accessibility Act references, what the US Department of Justice’s 2024 ADA rules reference, and what most enterprise procurement RFPs require. Level AAA exists but is rarely mandated and sometimes conflicts with reasonable design goals, so ignore it for now.

Start with the theme (this is half the battle)

Half of accessibility on WordPress is theme choice. An “accessibility-ready” tagged theme has been reviewed against the WordPress theme accessibility guidelines. A non-ready theme may or may not be accessible, and testing it retroactively is expensive.

Safe choices for a new build in 2026: Twenty Twenty-Four and Twenty Twenty-Five (both Gutenberg block themes, both accessibility-ready), GeneratePress, Astra with some care, Kadence with some care. Elementor and Divi base themes are workable but need hands-on audit of every template you ship. I have fixed enough Elementor sites to know that the defaults are not accessible enough to pass an audit without work.

Things to audit in any theme before committing to it:

• Focus indicator visibility on every interactive element (links, buttons, form fields). The focus ring must be visible, not just implied.
• Heading hierarchy on a rendered page (no h2 before h1, no level skips from h2 directly to h4).
• Skip-to-content link present and functional with keyboard.
• Landmark regions (header, nav, main, footer) wrapping the right content.
• Form field label associations (every input has a matching label with for attribute).

Color contrast (the easiest rule to break)

WCAG 2.2 AA requires four contrast thresholds that every WordPress site must meet:

• 4.5:1 contrast for normal body text against its background.
• 3:1 for large text (18pt and above regular, or 14pt and above bold).
• 3:1 for non-text UI components (button borders, form field borders, focus indicators).
• 3:1 for meaningful graphics and charts where color carries information.

Test with the built-in browser devtools contrast checker or axe DevTools. If your brand colors do not pass the 4.5:1 body text threshold, they do not pass. Resist the temptation to add “it is close enough” exceptions. Most brands have a compliant darker shade somewhere in the palette, and the legal exposure of shipping a non-compliant site is genuinely not worth the aesthetic argument. I have watched clients reverse design decisions after a single accessibility complaint letter, and the reversal is always more expensive than doing it right the first time.

In theme.json for block themes, define your palette once and reuse it. A rebrand then only requires contrast-testing the new palette once, not per-block.

Keyboard navigation (test this yourself, today)

Every interactive element on your site must be reachable with Tab, operable with Enter and Space (and arrow keys for widgets like menus and tabs), visible when focused, and reachable in a logical order that usually matches the visual order.

The quickest test anyone can run right now: load the site, press Tab from the very top of the page, and watch the focus ring. If you lose track of focus at any point, or if Tab jumps in an unexpected order, or if a modal does not trap focus, you have a problem that needs fixing.

Common WordPress culprits I see on nearly every site I audit:

• Mobile menus that trap focus inside the invisible menu. When the menu is hidden with display: none, focus should not be able to enter it. Many mobile menu plugins forget this.
• Slick and Swiper sliders with prev/next controls that are not keyboard-operable by default. Configure them explicitly with accessibility: true.
• Custom dropdowns that use hover-only or onclick without onkeydown. Keyboard users cannot open them.
• Modal dialogs that do not trap focus while open and do not return focus to the trigger element when closed.

Semantic HTML and ARIA: the rules that matter

The first rule of ARIA: if a native HTML element does the job, use the native element. <button> beats <div role="button"> every single time. ARIA is for widgets that have no native HTML equivalent, such as custom tabs, combobox, and disclosure patterns. Follow the ARIA Authoring Practices Guide for the specific pattern you are building.

The most overused ARIA attributes in WordPress plugins I review:

• aria-label on elements that already have a visible text label. This double-announces the element to screen reader users.
• role="button" on <a> tags. It makes them buttons semantically but they still behave like links in every other way, which confuses users.
• aria-hidden="true" on elements containing interactive content. This disables the whole subtree for screen readers, including buttons and links that users need to reach.

If you are ever tempted to write aria-role, stop. That is not a real attribute.

Accessible forms (this is where most sites fail)

Forms are where most WordPress sites fail an accessibility audit. Every form on your site needs:

• A visible <label> element associated via for and id attributes. Placeholder text is not a label, period.
• Required fields indicated visually AND with aria-required="true" (or simply the required attribute, which does both).
• Error messages that appear near the field, are associated with aria-describedby, and use role="alert" if they are announced dynamically.
• Submit buttons that say what they do (“Send message” or “Subscribe to newsletter”) not “Submit.”
• Error summaries on invalid submission that are focused programmatically, so keyboard users know something went wrong.

Gravity Forms, Fluent Forms, and WS Form all generate accessible markup by default. Contact Form 7 needs additional CSS and configuration to match the others, because the base output is not great. If accessibility matters to your client, skip Contact Form 7 and use one of the better options.

Images and media

• Every <img> needs an alt attribute. If the image is decorative (a background flourish, a divider), use alt="" (empty, not missing). WordPress’s media library supports this via the alt text field.
• Videos need captions. YouTube auto-captions are not compliant, they need review. For self-hosted video, upload a .vtt file alongside the video.
• Audio content needs a transcript, not just a description.
• Animations that are purely decorative should respect prefers-reduced-motion.

Accessibility plugins: the good and the dangerous

A small plugin like WP Accessibility (by Joe Dolson, a longtime core accessibility contributor) adds genuinely useful helpers: skip link enforcement, form label fixes, removal of title attribute duplication. This is fine and worth installing.

Overlay plugins that promise “one-click WCAG compliance” (AccessiBe, UserWay, EqualWeb, and similar) are different. They do not make a site compliant. They often break the assistive technology that users already have installed. They have been the subject of active lawsuits, and several overlays have been explicitly called out in complaints as making the site less accessible, not more. Do not use them as a primary compliance strategy.

The audit workflow I run on every client site

A repeatable audit sequence, in order, for every client site:

1. axe DevTools (browser extension) on every template: home, archive, single post, page, contact form, cart if e-commerce. Fix all Critical and Serious findings.
2. WAVE (browser extension) on the same pages. WAVE surfaces issues axe misses and vice versa, so running both is worth the extra 15 minutes.
3. Keyboard-only walkthrough of each critical flow: reach the menu, open a modal, submit a form, add to cart. If you cannot complete the flow without a mouse, your users cannot either.
4. Screen reader smoke test using NVDA on Windows or VoiceOver on macOS. You will catch issues that automated tools always miss, especially around dynamic content announcements and focus management after AJAX updates.
5. Contrast pass using DevTools or Colour Contrast Analyser on every text-over-background combination in the design system.

Automated tools catch roughly 30 to 40 percent of WCAG violations. The rest are found by the keyboard and screen reader passes, which is why they are non-negotiable in my workflow. Skip them and you will ship bugs to real users.

Keeping the site compliant after launch

Shipping a compliant site is not enough, because sites drift. Add three things to your ongoing process:

• An axe-core CI job that blocks pull requests introducing new Critical violations. This prevents regressions from ever reaching production.
• An accessibility checklist in every content editor’s publishing flow: alt text, heading structure, link text meaningful rather than “click here.”
• A quarterly manual audit calendar entry, not optional.

Compliance is a rolling responsibility, not a one-time certification. The sites that stay compliant are the ones that treat accessibility as part of the Definition of Done for every feature, not as a retrofit after launch. For a deeper look at WordPress publishing workflows that include accessibility gates, see my WordPress content calendar and publishing workflow guide.

The bottom line

WCAG 2.2 AA compliance on WordPress is genuinely achievable with an accessibility-ready theme, disciplined design choices, and a regular audit habit. The technical work is straightforward once you know the rules. The hard part is organizational: keeping the next homepage redesign, the next plugin integration, or the next content editor from silently reintroducing the issues you just fixed. That is not an accessibility problem, it is a culture problem, and the fix is documentation plus the CI gate.

ai block builder wordpress Beginner WordPress Tips First steps after WordPress install

Last modified: April 14, 2026