WCAG 2.2 audits for WordPress plugins
WCAG 2.2 became an ISO standard in 2025, and most plugins have never been checked against it. Our deterministic scanner validates the four new success criteria that apply to plugin code — with file:line evidence, not vibes.
What we check
SC 2.5.8 — Target Size Minimum (AA)
Interactive elements (buttons, inputs, toggles) with an explicit height or width below 24×24 CSS pixels and no min-size or padding compensation. Inline text links are excepted per the spec and never flagged.
SC 3.3.8 — Accessible Authentication (AA)
Login or authentication flows gated solely by a cognitive function test (CAPTCHA) with no alternative path — recovery codes, one-time codes, magic links, or passkeys. The most common failure we see in login-guard plugins.
SC 2.5.7 — Dragging Movements (AA)
Pointer-drag implementations (dragstart, draggable, mouse-based reordering) with no keyboard alternative in the same file. Sortable settings UIs are unusable for keyboard-only users.
SC 2.4.11 — Focus Not Obscured (AA)
Fixed or sticky overlay bars (cookie banners, notice bars, floating toolbars) with high z-index that can fully cover the element a keyboard user is focused on.
Why it's ahead of the curve
The European Accessibility Act references WCAG 2.1 today — which means WCAG 2.2 compliance is where the regulation is heading, not where it is. Plugins that pass 2.2 now are ahead of the EAA's next refresh, and have a genuine differentiator on their wp.org listing.
- Every finding includes the exact file and line, plus the WCAG criterion it maps to
- Deterministic only — no AI guessing; every check is a verifiable rule
- Inline text links are never flagged (the spec's own exception, honoured)
- Runs alongside the AI accessibility engine's WCAG 2.1 AA + EAA analysis
- Corroborates with AI findings: deterministic + engine agreement promotes confidence
- Included in every audit at every tier — including free