If you run a WordPress site, WCAG 2.2 is no longer something to “watch later.” It is the new accessibility standard many teams are using to guide design, development, and procurement decisions. While WCAG 2.1 is still referenced in some legal rules, WCAG 2.2 introduces practical updates that close real usability gaps for keyboard users, people with low vision, and people with mobility or dexterity limitations.
This post breaks down what WCAG 2.2 means for WordPress site owners, what the biggest WCAG changes are, and exactly what to update first. If you care about WordPress accessibility, this is the checklist-level view you need.
What WCAG 2.2 Changes in Practice
WCAG 2.2 became a W3C Recommendation in October 2023. It adds new success criteria (and updates a few expectations) to improve everyday interactions, especially for people navigating with keyboards, switch devices, touch, or voice input.
For WordPress site owners, the key point is this: accessibility standards are moving from broad “best practice” guidance to measurable interaction quality. That means focus styles, click targets, and drag alternatives are no longer minor UX polish. They are compliance and usability requirements.
Why this matters specifically for WordPress
WordPress powers a large share of the web (more than 40% of all websites, according to current industry usage tracking), so theme and plugin choices have outsized impact. A single inaccessible pattern in your theme, page builder, menu, or custom block can repeat across hundreds of pages.
In other words, WCAG 2.2 is not just a content team issue. It is a system issue across your theme, components, plugins, and QA workflow.
The Key WCAG 2.2 Success Criteria WordPress Owners Should Prioritize
1. Focus Appearance: keyboard focus must be visible and usable
WCAG 2.2 strengthens focus visibility requirements. Many WordPress themes still use faint outlines, color-only focus indicators, or styles that disappear against certain backgrounds. That creates a major barrier for keyboard users who rely on visible focus to know where they are on a page.
Common WordPress failure patterns include:
- Focus outline removed with CSS (for example, global
outline: none;) - Focus style too low-contrast against button or page backgrounds
- Inconsistent focus style across native elements, Gutenberg blocks, and plugin UI
- Focus trapped in popups, mega menus, or modal forms
What to do now: define one strong, high-contrast focus token in your design system and apply it consistently to links, buttons, form controls, menu items, and custom interactive blocks.
2. Dragging Movements: provide a no-drag alternative
WCAG 2.2 adds a clear requirement: if an interaction depends on dragging, users must have another way to complete the same action. This affects sliders, map pins, sortable lists, and drag-and-drop widgets used in front-end experiences.
Typical WordPress risk areas:
- Before/after image sliders that only respond to drag gestures
- Custom range controls without keyboard alternatives
- Interactive booking or filtering widgets that require pointer dragging
What to do now: ensure each drag interaction has accessible alternatives such as click-to-move controls, arrow-key support, numeric input, or explicit “move up/down” actions.
3. Target Size (Minimum): make touch and click targets easier to activate
WCAG 2.2 introduces target size expectations so controls are not too small or tightly packed. On WordPress sites, this is a frequent issue in mobile menus, icon-only links, pagination controls, and dense form layouts.
High-risk components include:
- Social icons in headers/footers
- Tiny “close,” “search,” or “menu” icons
- Inline text links placed too close together
- Calendar, filter, and faceted-search controls in ecommerce themes
What to do now: increase interactive hit areas, add spacing between adjacent controls, and test on real mobile devices with zoom and assistive technology enabled.
WordPress Accessibility Action Plan for WCAG 2.2
Most teams don’t need a full rebuild. They need a focused remediation plan tied to the WCAG changes that create the most user friction and compliance risk.
Audit the interaction layer first
- Test keyboard-only navigation across templates: home, service, blog, product, checkout/contact, and search.
- Record where focus becomes invisible, confusing, or trapped.
- Identify drag-only features and define equivalent non-drag controls.
- Measure target size and spacing for all critical conversion paths on mobile.
Fix global patterns before page-level content
In WordPress, global code fixes in themes and shared components deliver the biggest ROI. Update your base button, link, form, modal, and navigation patterns first. Then handle one-off block and plugin edge cases.
Prioritize fixes in this order:
- Theme CSS and JavaScript patterns used site-wide
- Reusable Gutenberg blocks and block style variations
- Third-party plugin interfaces exposed to visitors
- Template-specific exceptions
Build ongoing checks into your publishing workflow
WCAG 2.2 compliance is not a one-time launch task. Theme updates, plugin updates, and new content can reintroduce failures quickly. Add recurring scans and regression checks so accessibility standards stay enforced over time.
Why Overlay Widgets Are Not Enough
Many site owners try overlay widgets because they seem fast. The problem is that overlays usually modify presentation at runtime rather than correcting underlying code defects. If focus logic, semantic structure, keyboard behavior, or control size is broken in source code, an overlay often cannot fully solve it.
That is especially relevant for WCAG 2.2. The new criteria are heavily interaction-focused. They require robust behavior in the actual interface, not just a visual layer on top.
How LEWCA Supports WCAG 2.2 Readiness
LEWCA is built for code-level WordPress accessibility work. Instead of acting as a third-party overlay widget, it scans your site for WCAG issues and helps you implement real fixes in the underlying code and markup. LEWCA also includes a built-in, admin-controlled visitor accessibility toolbar that is self-hosted alongside those code changes.
For teams addressing WCAG 2.2, that means you can:
- Identify focus appearance failures across templates and components
- Catch interaction patterns that rely on dragging without alternatives
- Detect target size and interactive control issues that hurt mobile usability
- Apply durable fixes that survive theme and plugin evolution
If your goal is sustainable WordPress accessibility aligned with modern WCAG changes, code-level remediation is the path that scales.
Next Step: Turn WCAG 2.2 Into an Implementation Plan
WCAG 2.2 does not require panic. It requires prioritization. Start with focus appearance, dragging alternatives, and target size on your most important user flows, then standardize fixes in your WordPress theme and shared blocks.
Ready to move from scanning to real remediation? Explore LEWCA pricing or download LEWCA to start fixing WCAG issues at the code level.