WCAG 2.1 vs 2.2 Differences That Affect Sites

A website can meet WCAG 2.1 AA and still have accessibility barriers that WCAG 2.2 specifically addresses. That is the practical issue behind the WCAG 2.1 vs 2.2 differences: WCAG 2.2 does not replace the earlier standard’s foundation, but it adds nine success criteria that affect how users navigate, authenticate, interact with forms, and maintain focus on a page.

For WordPress site owners, agencies, schools, and public entities, the update matters because accessibility work is rarely limited to a single page or template. New requirements can affect theme components, page builder modules, ecommerce flows, embedded tools, custom forms, menus, document links, and publishing procedures. A credible compliance process must evaluate both the code and the real user journey.

WCAG 2.1 vs 2.2 Differences at a Glance

WCAG 2.2 retains the WCAG 2.1 success criteria and adds nine new criteria. It also removes one criterion, 4.1.1 Parsing, which was part of WCAG 2.0 and 2.1. The removal does not mean invalid markup is harmless. Clean, properly structured HTML remains essential for assistive technology compatibility, reliable browser behavior, and maintainable WordPress development. It simply means parsing is no longer a separately tested WCAG 2.2 conformance requirement.

Of the nine additions, six are Level A or AA requirements. These are the criteria most likely to affect organizations targeting WCAG 2.2 AA, which is commonly used as the practical benchmark for public-facing accessibility programs. The other three are Level AAA, offering additional support but not typically forming the baseline for a sitewide conformance target.

The update has a clear direction: reduce friction for people using keyboards, touch interfaces, screen magnification, speech input, cognitive supports, and alternative authentication methods. Several new criteria address common failures in modern interfaces, particularly sticky headers, persistent chat controls, drag-and-drop features, repeated data entry, and login experiences.

The New Level A and AA Requirements

Focus not obscured: minimum and enhanced

WCAG 2.2 adds Focus Not Obscured (Minimum) at Level AA and Focus Not Obscured (Enhanced) at Level AAA. Keyboard focus must remain visible when a user tabs through interactive elements. At the AA level, the focused component cannot be entirely hidden by author-created content, such as a sticky navigation bar, cookie banner, floating accessibility control, chat widget, or promotional overlay.

This is a frequent WordPress issue because themes and plugins increasingly use fixed-position elements. A user may tab to a link or form field that sits behind a persistent header, leaving them unable to see where they are. Developers should test keyboard paths at multiple viewport sizes, including zoomed layouts. It is not enough for a focus indicator to exist if an overlay covers it.

Focus appearance

Focus Appearance is a Level AA requirement that sets a measurable baseline for visible keyboard focus indicators. The criterion addresses the widespread practice of removing browser focus outlines and replacing them with subtle effects that are difficult to detect.

A compliant focus treatment needs sufficient contrast and visible area. In practical terms, WordPress teams should use a clear outline, border, background change, or similar indicator that remains obvious against surrounding content. Test it on navigation links, buttons, form fields, accordions, modal controls, product filters, and page builder widgets. A focus style that works on one button color may disappear on another.

Dragging movements

Dragging Movements is a Level AA criterion. If a function requires dragging, the site must provide a single-pointer alternative unless dragging is essential. Examples include rearranging items, moving a slider handle, adjusting an image crop area, or positioning an object on a map.

This does not prohibit drag-and-drop interactions. It requires another workable method, such as move-up and move-down buttons, numeric controls, selectable positions, or click-based actions. The distinction matters for users who cannot perform a precise dragging gesture with a mouse, trackpad, touchscreen, or alternative input device.

Target size: minimum

Target Size (Minimum), at Level AA, generally requires pointer targets to be at least 24 by 24 CSS pixels or have enough spacing from adjacent targets. The criterion includes exceptions, including inline text links and targets whose small size is essential to the function.

Small controls are common in WordPress sites: carousel arrows, close buttons, social icons, pagination links, filter controls, calendar dates, and mobile menu toggles. A visual design can look polished while still creating an error-prone experience for people with limited dexterity or users operating a phone with one hand. Audit interactive elements in their actual responsive layouts rather than judging only desktop screenshots.

Consistent help

Consistent Help is a Level A criterion. When a page provides help mechanisms that repeat across a set of pages, such as contact details, self-service support, live chat, or a help link, they must appear in the same relative order unless a user initiates a change.

This requirement is especially relevant to large WordPress sites with different templates, departmental sections, ecommerce pages, and third-party widgets. Help does not need to appear on every page. But when it is available repeatedly, users should not have to relearn where to find it on each section of the site.

Redundant entry

Redundant Entry, also Level A, requires sites to avoid asking users to re-enter information that they have already provided in the same process. Exceptions apply when re-entry is essential, required for security, or when prior information is no longer valid.

Consider a multi-step application, checkout, registration, or appointment process. If a user enters their name, address, or account details on one step, later stages should populate that information or allow the user to select it. This reduces cognitive load and prevents avoidable errors. It also requires careful testing of form plugins, ecommerce extensions, custom workflow code, and integrations.

Accessible authentication

Accessible Authentication is Level AA and has a stronger Level AAA version. The AA requirement prevents authentication steps from relying on a cognitive function test unless an alternative is available. Users should not be forced to solve puzzles, remember a password, transcribe codes from an image, or identify objects solely to sign in.

Support for password managers and copy-and-paste is a central practical consideration. A login form that blocks pasted passwords can create an accessibility barrier and weaken security practices at the same time. Authentication flows should also be reviewed when CAPTCHA, two-factor authentication, identity providers, membership plugins, and payment systems are involved.

The New Level AAA Criteria

WCAG 2.2 also adds Focus Not Obscured (Enhanced), Target Size (Enhanced), and Accessible Authentication (No Exception) at Level AAA. These criteria establish a higher threshold for organizations that choose to exceed AA requirements.

For example, Target Size (Enhanced) generally calls for 44 by 44 CSS pixel targets. That can be a valuable internal design standard for touch-friendly interfaces, even when AA is the formal conformance target. However, AAA conformance across a large, content-heavy site may be impractical. The appropriate target depends on the organization’s legal obligations, audience, service complexity, design system, and risk tolerance.

What WCAG 2.2 Changes in a WordPress Audit

A WCAG 2.1 audit that focuses mainly on missing alternative text, heading structure, color contrast, and form labels will not fully cover WCAG 2.2. Those core checks remain necessary, but the new criteria require more behavioral and layout-based testing.

Automated scanning can identify many accessibility failures and flag patterns for review across posts, pages, templates, menus, widgets, and other WordPress content. It can also help teams locate recurring problems, such as weak focus styling or undersized controls. But some WCAG 2.2 requirements require manual validation because the answer depends on interaction behavior: whether focus is hidden at a particular scroll position, whether a drag operation has an alternative, or whether a workflow repeats entered data.

An effective audit should combine automated detection with targeted keyboard, zoom, mobile, and workflow testing. It should include theme files and custom components, not just published page content. WP ADA Compliance Check supports this process by scanning WordPress environments against WCAG 2.1, WCAG 2.2, and Section 508 standards while providing error details and remediation guidance within the publishing workflow.

Prioritize the Highest-Risk Areas First

Do not treat WCAG 2.2 as a reason to restart a mature accessibility program. Start by identifying interfaces with the greatest user and compliance impact: login pages, checkout and payment steps, online forms, navigation systems, search and filters, account dashboards, appointment tools, and pages with fixed overlays.

Then test the components that repeat throughout the site. A single inaccessible menu toggle, focus rule, cookie banner, or form template can affect hundreds of URLs. Correcting shared components is usually more efficient than addressing isolated page-level symptoms.

For organizations working with vendors, document ownership early. A WordPress administrator may control content and settings, while a theme developer controls focus behavior and a third party controls a chat or scheduling interface. The standard applies to the user experience regardless of who supplied the component, so vendor review belongs in the remediation plan.

WCAG 2.2 is best treated as an operational requirement, not a one-time checklist. Build its tests into theme updates, plugin reviews, content approval, and release quality assurance. That approach gives teams a practical way to prevent new barriers while steadily reducing the accessibility risk already present across the site.