Best WordPress Plugins for WCAG 2.2 Compliance (2026)

Best WordPress Plugins for WCAG 2.2 Compliance (2026) - TheMealley buyer guide

Most WordPress accessibility content still targets WCAG 2.1, which is reasonable because that is what EN 301 549 currently incorporates. It is also about to be out of date: EN 301 549 v4.1.1 is expected to publish during 2026, and once it appears in the Official Journal of the EU it is likely to become the technical standard for European Accessibility Act compliance. That version adopts WCAG 2.2.

In the US the shift has already happened for public bodies. The Department of Justice final rule requires state and local government websites to meet WCAG 2.2 Level AA, with entities serving populations of 50,000 or more required to comply by 24 April 2026. So 2.2 is the target to build against now. This article covers the nine new success criteria in plain language, which of them tooling can help with, and which are design decisions no plugin will make for you.

Verified August 2026. Related: our EAA compliance guide and our piece on why overlays attract lawsuits.


The nine new criteria, in plain language

WCAG 2.2 adds nine success criteria to 2.1 and removes one. The additions cluster around three themes: keeping focus visible and usable, reducing physical precision requirements, and reducing cognitive load during authentication and multi-step processes.

  • Focus Not Obscured. When something receives keyboard focus, it must not be hidden behind a sticky header, a cookie banner, or a chat widget. This is the criterion most WordPress sites fail, because sticky headers are everywhere.
  • Focus Appearance. The focus indicator must be big enough and contrast enough to see. Themes that suppress the default outline for aesthetic reasons fail here.
  • Dragging Movements. Anything achievable by dragging must also be achievable without dragging. Sliders, sortable lists, and range selectors are the usual offenders.
  • Target Size (Minimum). Interactive targets need adequate size or spacing. Cramped icon rows and tightly packed mobile menus fail.
  • Consistent Help. If help is available, it appears in the same relative place across pages.
  • Redundant Entry. Do not make people re-enter information they already gave you in the same process. Multi-step checkouts are the common failure.
  • Accessible Authentication. Do not require a cognitive test to log in. This puts pressure on puzzle CAPTCHAs and on transcribing codes between devices.

Read that list against a typical WordPress site and the pattern is clear: most failures come from the theme and from third-party widgets, not from your content. That matters for tool choice, because content scanners look at content.


The 6 tools compared

1. Equalize Digital Accessibility Checker

The best WordPress-native option, scanning content in the editor across more than 40 checks and flagging issues before publication. Its free version is genuinely usable, and paid plans start at $190 a year with unlimited page scanning and no per-page or API fees, which for a large site is the important commercial detail.

For 2.2 specifically, its value is on the content-side criteria: redundant entry in forms you build, consistent help placement, and the 2.1 foundations that still make up most of the standard. It will not tell you your sticky header obscures focus, because that is a theme behaviour visible only when you tab through a rendered page. Pair it with the browser tools below and you cover both halves.

  • Pricing: Free version; paid from $190 a year, unlimited pages
  • Covers: Content-side criteria, in the editor
  • Best for: Stopping new issues at authoring time
  • Watch out for: Theme-level focus and target issues need browser testing

2. axe DevTools

The developer standard, free in its browser extension form, and the most reliable automated engine in general use. axe-core underpins a great many other tools, so its rule coverage is effectively the industry baseline for what machines can detect.

For 2.2 it is the practical way to check target size and focus appearance on a rendered page, because those are computed properties of the live DOM rather than facts about your content. Run it on a page with your header sticky and a cookie banner showing, since that combination is where focus obscuring appears and where a clean scan of a bare page will mislead you. Output is developer-oriented, which is a limitation for content teams and a strength for anyone fixing theme CSS.

  • Pricing: Free extension; paid tiers for teams
  • Covers: Rendered-page criteria including target size and focus
  • Best for: Checking the criteria that depend on layout
  • Watch out for: Developer output; test with banners and headers present

3. WAVE

WebAIM’s tool, free as a browser extension, and the most approachable of the automated scanners because it annotates the page visually rather than producing a list of rule violations. For a non-specialist being asked to improve accessibility, seeing icons attached to the actual elements is considerably more useful than a report.

Its contrast checker is the standout, and contrast remains one of the most common failures on WordPress sites. API access is available from around $100 a month for 1,000 page credits if you want to scan programmatically, though for most sites the free extension plus a systematic pass through your templates is sufficient. Like every scanner it is bounded by the automation ceiling, and it does not know whether your alternative text is meaningful.

  • Pricing: Free extension; API from around $100 a month
  • Covers: Visual annotation, strong contrast checking
  • Best for: Non-specialists who need to see the problem
  • Watch out for: One page at a time in the free version

4. Pa11y CI

Completely free and open source, and the only option here that prevents regressions rather than reporting them. Pa11y CI runs against a URL list during a build and fails the build when new issues appear, which changes accessibility from a periodic cleanup into a standard nobody can breach accidentally.

For a team adopting 2.2, this is the way to hold the line once you have done the remediation work. Set your baseline after the initial fixes, and every subsequent theme change or plugin update that introduces a violation gets caught before release. It requires a deployment pipeline and someone comfortable configuring it, which rules it out for many small sites and makes it close to essential for anyone with a staging workflow.

  • Pricing: Free, open source
  • Covers: Automated regression prevention in CI
  • Best for: Holding a standard once you have reached it
  • Watch out for: Needs a build process and technical setup

5. Silktide

A governance platform crawling a whole site and reporting accessibility alongside content quality and SEO, with prioritisation and progress tracking over time. For an organisation that has to demonstrate movement toward 2.2 rather than simply claim it, that reporting is what you are buying.

Pricing is custom-quoted and typically 30% to 50% less than Siteimprove, which still means thousands per year. It makes sense for public bodies working to the April 2026 DOJ deadline with multiple sites and several content teams, where the coordination problem is as large as the technical one. A single WordPress site chasing 2.2 does not need this, and Equalize Digital plus free browser tools covers the same ground for $190.

  • Pricing: Custom quote, typically 30% to 50% below Siteimprove
  • Covers: Site-wide crawling, prioritisation, progress reporting
  • Best for: Public bodies and multi-site estates with deadlines
  • Watch out for: Enterprise cost for a single-site requirement

6. Manual keyboard and screen reader testing

Free, and for WCAG 2.2 specifically it is not optional. Several of the new criteria are only observable by using the page: whether focus is obscured, whether a dragging interaction has an alternative, whether authentication demands a cognitive test.

The minimum viable test takes an afternoon. Unplug your mouse and tab through your homepage, a content page, and your checkout, watching where focus goes and whether you can always see it. Try every slider and drag interaction with the keyboard alone. Log in without a password manager and see whether you are asked to solve anything. Then repeat with a screen reader on your most important journey. Automated tools detect roughly 30% of WCAG issues; this is how you reach the rest, and it costs nothing but time.

  • Pricing: Free
  • Covers: The criteria no scanner can evaluate
  • Best for: Everyone, without exception
  • Watch out for: Needs doing again after theme and plugin changes

Comparison table

ToolCostContent criteriaLayout criteriaRegression prevention
Equalize DigitalFree, or $190/yrYesLimitedAt authoring time
axe DevToolsFree extensionYesYesNo
WAVEFree; API ~$100/moYesContrastNo
Pa11y CIFreeYesYesYes, in the build
SilktideThousandsYesYesTracking only
Manual testingFreeYesYesNo

The 2.2 criteria a plugin will never fix

Three of the new criteria are design decisions, and recognising that saves you from buying a tool expecting it to solve them.

Focus Not Obscured is usually caused by a sticky header, a cookie banner, or a chat bubble covering the focused element as you tab down the page. The fix is CSS scroll padding, reducing sticky element height, or reconsidering whether the element needs to be sticky at all. No scanner will make that call for you, and it is the single most common 2.2 failure on WordPress sites.

Accessible Authentication puts direct pressure on puzzle CAPTCHAs, which require exactly the cognitive function the criterion says you must not demand. It also affects login flows that make people transcribe a code from one device to another without allowing paste. The fixes are moving to a non-cognitive challenge, allowing password managers and paste, and supporting passkeys where you can.

Redundant Entry most often fails in multi-step checkouts that ask for a shipping address and then a billing address with no option to copy, or forms that lose entries when validation fails. Both are configuration and template decisions rather than plugin settings, and both are worth fixing regardless of the standard because they cost conversions.



Related guides

Frequently asked questions

Should I target 2.1 or 2.2?

2.2. The current EN 301 549 incorporates 2.1, but v4.1.1 is expected in 2026 and adopts 2.2, and the DOJ rule already requires 2.2 AA for US public bodies. The additions are modest; auditing twice is not.

Which new criterion do most sites fail?

Focus Not Obscured, because sticky headers are near-universal in modern themes and almost nobody tabs through their own site to check. It takes five minutes to test and is often a small CSS fix.

Does WCAG 2.2 break 2.1 conformance?

No. 2.2 is additive apart from one removed criterion, so 2.1 work carries forward. You are adding checks rather than redoing anything.

Can automated tools test the new criteria?

Partially. Target size and focus appearance are computable and axe handles them. Focus obscuring, dragging alternatives, and accessible authentication need a person using the page.

Does my CAPTCHA fail Accessible Authentication?

If it requires solving a puzzle, identifying objects, or transcribing distorted text, it is a cognitive function test and it is a problem. Invisible challenges and honeypots do not have this issue, and they are usually better for conversion too.

How often should I re-test?

After every theme change, page builder update, or new third-party widget, since those are what break focus and target criteria. Automated checks in CI make this continuous; otherwise a quarterly keyboard pass is a reasonable minimum.


The verdict

For most WordPress sites: Equalize Digital at $190 a year for the content side, plus free axe DevTools and WAVE for the rendered-page criteria that a content scanner cannot see. Under $200 covers both halves of 2.2.

If you have a build process: add Pa11y CI, free, and set your baseline after remediation so no future change quietly reintroduces a failure.

For public bodies working to April 2026: Silktide or Siteimprove, because the coordination and evidencing problem across multiple sites and teams is as real as the technical one.

And spend an afternoon with your mouse unplugged. Three of the nine new criteria are only visible that way, Focus Not Obscured is the most commonly failed of them, and no tool in this article will tell you about it.