Which WCAG Version Applies to Your Website?
A website can pass one accessibility standard and still fall short of a contract, agency requirement, or lawsuit settlement. That is why asking which WCAG version applies is more useful than simply asking whether a site is “WCAG compliant.” The answer depends on who operates the site, where it is used, what legal or procurement requirements govern it, and whether a newer success criterion addresses a real barrier on your pages.
For most US organizations, WCAG 2.1 Level AA remains the practical baseline. WCAG 2.2 Level AA is increasingly the stronger target for new work, major redesigns, and ongoing accessibility programs. But neither version automatically replaces the specific requirements written into a federal rule, state policy, vendor contract, grant condition, or legal agreement.
Which WCAG Version Applies? Start With the Requirement
WCAG is published by the World Wide Web Consortium as a technical standard for web accessibility. It is not, by itself, a US law. Laws and policies reference WCAG versions and conformance levels to define what an organization must meet.
The first step is to identify the controlling requirement rather than choosing a version based on what is newest. Review your governing regulation, procurement documents, accessibility policy, settlement agreement, customer contract, and any standards imposed by a parent organization. The wording matters. A requirement that says “WCAG 2.1 AA” is different from one that says “WCAG 2.2 AA or the current version.”
If no document identifies a version, WCAG 2.2 Level AA is generally the sensible operational target for a website being built or substantially updated now. It includes all WCAG 2.1 success criteria plus additional requirements that address common usability barriers, especially for people using keyboards, touch devices, and authentication flows.
That recommendation does not mean an organization can ignore a stated WCAG 2.0 or WCAG 2.1 obligation. It means the team should meet the stated requirement while using the newer standard to reduce known accessibility gaps where feasible.
WCAG 2.0, 2.1, and 2.2: What Changes
The WCAG 2.x versions are cumulative. WCAG 2.1 includes the requirements in WCAG 2.0, and WCAG 2.2 includes the requirements in WCAG 2.1. A page that conforms to WCAG 2.2 Level AA also conforms to WCAG 2.1 and 2.0 at the same level, assuming the conformance claim is accurate.
WCAG 2.0 established the familiar framework organized around four principles: content must be perceivable, operable, understandable, and robust. It remains relevant because many older policies, contracts, and accessibility statements cite it directly.
WCAG 2.1 added criteria intended to improve access for mobile users, people with low vision, and people with cognitive or learning disabilities. It introduced requirements involving reflow, text spacing, orientation, touch input, and status messages, among others. For a modern WordPress site, these additions matter because responsive layouts, page builders, menus, forms, and embedded tools can create problems that a WCAG 2.0-only review may miss.
WCAG 2.2 adds nine new success criteria and removes one obsolete criterion, 4.1.1 Parsing. Its practical impact is strongest in interactive experiences. New requirements address visible keyboard focus, focus not being hidden by sticky elements or overlays, drag-and-drop alternatives, target sizes, redundant entry, accessible authentication, and consistent help placement.
These are not edge cases. A fixed cookie banner that covers a focused button, a form that makes users re-enter information, or a login process that blocks password managers can create a significant barrier even when the site appears visually polished.
Level A, AA, and AAA are not interchangeable
Version is only one part of the requirement. WCAG also has conformance levels: A, AA, and AAA. Level A addresses fundamental barriers. Level AA adds requirements that are widely treated as the expected benchmark for public-facing websites. Level AAA includes criteria that can be valuable but are not practical or applicable for every type of content.
For most organizations, the relevant target is WCAG 2.1 AA or WCAG 2.2 AA. Do not treat “we meet some AAA criteria” as a substitute for satisfying every applicable A and AA requirement. Accessibility conformance is based on the full set of applicable success criteria, not a score or a collection of favorable test results.
Common US Requirements and Their WCAG Targets
Federal agencies and organizations covered by Section 508 should look first to the Revised 508 Standards. Those standards incorporate WCAG 2.0 Level A and AA success criteria for web content, with certain exceptions and additional provisions. If Section 508 is your controlling rule, WCAG 2.0 AA is the formal reference point, even though testing against WCAG 2.1 or 2.2 can identify additional barriers worth correcting.
State and local government requirements vary. Some state digital accessibility policies reference WCAG 2.0 AA, while newer policies and procurement specifications may require WCAG 2.1 AA or WCAG 2.2 AA. Educational institutions face a similar reality. A university may follow system-wide standards, grant requirements, or procurement rules that go beyond the minimum language in a particular regulation.
For private businesses, the Americans with Disabilities Act does not set one universally codified WCAG version for all websites. However, WCAG Level AA is commonly used as the technical benchmark in demand letters, settlements, consent decrees, customer requirements, and accessibility programs. WCAG 2.1 AA is often named in recent agreements, and WCAG 2.2 AA is becoming more relevant as organizations update their policies and vendor expectations.
A business selling to government, higher education, healthcare, or enterprise customers should not wait for a lawsuit or procurement rejection to establish its target. Customer contracts can impose a standard that is more specific than general legal guidance.
When WCAG 2.2 AA Should Be Your Default
Use WCAG 2.2 AA as the default target when you are launching a new WordPress site, replacing a theme, rebuilding templates, selecting plugins, or setting an agency-wide development standard. It is the current WCAG 2.x recommendation and provides better coverage for modern interaction patterns.
It is particularly relevant when your site includes account login, checkout, registration, appointment scheduling, donations, course platforms, searchable databases, or other multi-step forms. These experiences depend heavily on focus behavior, controls that work without dragging, adequate tap targets, and authentication methods that do not create unnecessary barriers.
There is a trade-off. Some third-party tools and older themes may not yet document WCAG 2.2 support, and remediation can require custom development. That does not justify leaving barriers in place. It does mean teams should identify those dependencies early, document the risk, pursue an accessible alternative or vendor fix, and avoid introducing the same problem in new content.
Apply the Standard to the Whole WordPress Environment
A WCAG target is only useful if your audit covers the actual site visitors use. Reviewing a handful of blog posts is not enough when the accessibility issue is in the global header, navigation menu, form plugin, page-builder template, PDF library, search results, or embedded booking tool.
WordPress sites often distribute accessibility responsibility across multiple people and systems. Content editors control heading order, alternative text, link language, tables, and uploaded documents. Developers control theme markup, keyboard behavior, responsive layouts, and custom components. Plugin vendors may control sliders, popups, forms, ecommerce workflows, and accessibility widgets. A compliance process must account for all of them.
Automated scanning is an efficient first layer because it can identify recurring issues at scale, including missing image alternative text, empty links, heading problems, color-related concerns, form labels, and structural markup errors. It also helps teams find where an issue appears so it can be corrected in the right post, template, widget, or code file.
Automation does not replace manual verification. Keyboard navigation, focus visibility, meaningful alternative text, reading order, error messaging, video captions, and the accessibility of many third-party interactions require human review. The strongest workflow combines recurring automated audits with targeted manual testing of high-traffic and high-risk user journeys.
For WordPress administrators, a tool such as WP ADA Compliance Check can make that workflow more manageable by scanning published content and broader site components, reporting specific error locations, and supporting remediation before inaccessible content becomes a routine publishing problem.
Build a Policy That Does Not Age Out
The most useful accessibility policy does more than state “we follow WCAG.” It identifies a version, a conformance level, the scope of covered digital content, responsible teams, testing frequency, approval requirements, and an exception process. It should also explain how the organization handles third-party products, legacy PDFs, and content that cannot be immediately remediated.
If your formal obligation names WCAG 2.1 AA, write that clearly. Then consider an internal standard such as: new templates and major feature work must also be evaluated against applicable WCAG 2.2 AA criteria. This approach respects the stated requirement while preventing your program from falling behind current accessibility practice.
Accessibility is not a one-time certification event. Themes change, plugins update, editors publish new pages, and forms evolve. Choose the WCAG version required by your governing obligation, use WCAG 2.2 AA to guide new work whenever possible, and make ongoing testing part of how your WordPress site is managed.
