WCAG 2.2 Explained in Plain English
Most people who encounter WCAG treat it like a government checklist: a list of boxes to tick before a regulator comes knocking. That is the wrong mental..
Most people who encounter WCAG treat it like a government checklist: a list of boxes to tick before a regulator comes knocking. That is the wrong mental model, and it makes the whole subject harder than it needs to be. WCAG is a design framework built around four principles of human perception. Once you understand those principles, the individual rules stop feeling arbitrary and start making obvious sense.
Video: WCAG 2.2 Explained in Plain English
This article walks through WCAG 2.2 from the ground up: what the four principles require, what the conformance levels actually mean, what changed in the latest version, and how the standard connects to real legal obligations. By the end, you will have a clear picture of what WCAG 2.2 AA asks of your website and a concrete set of first steps to get there.
WCAG Is Not a Checklist. It Is a Framework Built on Four Principles.
WCAG stands for Web Content Accessibility Guidelines. The W3C, the international standards body for the web, publishes it. But the bureaucratic name obscures something important: the standard is built on four principles that describe how human beings experience digital content.
Those four principles form the acronym POUR: Perceivable, Operable, Understandable, Robust. Every success criterion in WCAG maps back to one of them. Understand POUR and you understand the logic behind every rule in the standard, including the ones you have not read yet.
WCAG 2.2 is the current published version, released in October 2023. It builds on WCAG 2.1 (2018) and 2.0 (2008), adding nine new or updated success criteria while keeping everything from earlier versions. If your site met WCAG 2.1 AA, you are close to 2.2 but not quite there. The differences are covered below.
Perceivable: If a User Cannot Sense It, It Does Not Exist
Perceivable means every piece of information on your site must be available to every user’s senses, or to the assistive technology that substitutes for those senses. If a user cannot perceive something, it simply does not exist for them.
The classic failure is an image with no alt text. A sighted user sees a product photo. A screen reader user hears nothing, or worse, hears the filename read aloud: “IMG_4872.jpg.” The information the image conveys has vanished entirely. The same principle applies to videos without captions. A deaf user gets nothing from an uncaptioned product demo, regardless of production quality.
Perceivable also covers contrast. Text that is light grey on a white background may look clean to a designer but is effectively invisible to someone with low vision or colour deficiency. WCAG 2.2 AA requires a contrast ratio of at least 4.5:1 for normal text. That is not an aesthetic preference. It is the threshold at which most users with low contrast sensitivity can actually read the words.
Operable: Every Function Must Work Without a Mouse
Operable means users can navigate and interact with everything on your site regardless of how they control their device. Many users cannot use a mouse. They navigate with a keyboard, a switch device, eye-tracking software, or another assistive input method.
The most common failure is a navigation dropdown that only opens on hover. A keyboard user tabs to the menu item, presses Enter, and nothing happens. They cannot reach any of the sub-pages. The site is functionally broken for them, not because content is missing, but because the interaction requires a pointing device.
Operable also covers time limits and seizure risks. An auto-advancing carousel that moves every three seconds leaves users who need more time unable to read the content. An animation with rapid flashing risks triggering photosensitive seizures. These are not edge cases. Under WCAG 2.2, the Operable principle gained two new criteria that directly address real interaction problems, covered in the section below.
Understandable: Language and Behaviour Should Not Surprise Users
Understandable means users can comprehend both the content and how the interface works. It is the principle most often overlooked because it feels softer than the others, but its failures are everywhere.
Consider a checkout form that returns “Invalid input” after the user submits their credit card details. The error message is present. It tells the user nothing. Is it the card number? The expiry date? The billing postcode? An understandable error message names the field, explains what went wrong, and suggests how to fix it. “Please enter a 16-digit card number without spaces” is understandable. “Invalid input” is not.
Understandable also requires consistent navigation. If your site’s main menu appears in a different position on different pages, users with cognitive disabilities, or anyone relying on spatial memory, get disoriented. The principle requires that navigation stays predictable, that pages behave the way users expect, and that no sudden page refresh fires when a form field is selected.
Robust: Your Code Must Work With Assistive Technology Today and Tomorrow
Robust is the most technical of the four principles, but its meaning is straightforward: your HTML needs to be clean enough that assistive technologies can interpret it correctly, now and as those technologies evolve.
The practical failure is misused or missing ARIA. ARIA (Accessible Rich Internet Applications) is a set of HTML attributes that communicate the role, state, and properties of interface elements to screen readers. Used correctly, ARIA makes complex widgets like modal dialogs, accordions, and tabs accessible. Used incorrectly, or bolted onto broken HTML, it produces a worse experience than no ARIA at all.
Robust also means your code validates. A screen reader encountering malformed HTML makes guesses about document structure. Buttons coded as divs, form fields without labels, and heading levels that skip from H1 to H4 all create structural ambiguity that assistive technologies handle inconsistently. You do not need to be a developer to care about this. You need to know that code quality has a direct relationship to whether assistive technology users can use your site at all.
Level A, AA, and AAA: What “Passing” Actually Means
WCAG organises its success criteria into three conformance levels: A, AA, and AAA.
Level A is the baseline. These are the criteria that, if unmet, create absolute barriers for some users. Missing alt text on an informative image is a Level A failure. So is a form that cannot be completed with a keyboard. Level A is not optional. Failing it means some users literally cannot access part of your site.
Level AA is the practical target for almost everyone. It builds on A and adds criteria that address the most common usability barriers: colour contrast, captions for live video, visible focus indicators, consistent navigation. When laws reference WCAG compliance, they mean Level AA. When courts assess whether a website is accessible under the ADA, they measure against AA. When the European Accessibility Act sets its standard, it requires AA. Level AA is the line between “accessible enough to be defensible” and “probably a problem.”
Level AAA is aspirational. It contains the most demanding criteria: sign language interpretation for all video content, reading level that requires no secondary education, no time limits of any kind. AAA is worth pursuing where possible, but it is not a realistic whole-site target for most organisations, and no major law requires it.
According to the 2025 WebAIM Million report, 94.8% of the top one million home pages contain detectable WCAG 2 A/AA failures. The overwhelming majority of websites are not passing the baseline standard, let alone the full AA target. To see where your site stands, you can run a free WCAG scan and get a breakdown of failures by principle and level.
What Is New in WCAG 2.2 – and Why It Matters
WCAG 2.2 added nine new or updated success criteria to what existed in 2.1. Most address problems that are genuinely common and genuinely frustrating, particularly for users with motor disabilities and cognitive impairments.
Focus Appearance (2.4.11, Level AA) requires that keyboard focus indicators meet a minimum size and contrast threshold. Previously, “visible focus” was required but not precisely defined. Many sites implemented a barely-there dotted border that technically qualified but was nearly impossible to see in practice. WCAG 2.2 closes that gap with specific measurements.
Dragging Movements (2.5.7, Level AA) requires that any functionality using a dragging gesture (sliders, map panning, drag-and-drop interfaces) can also be performed with a single pointer action. Dragging is difficult or impossible for many users with motor impairments. This criterion ensures an alternative always exists.
Target Size Minimum (2.5.8, Level AA) sets a minimum size of 24 by 24 CSS pixels for interactive targets like buttons and links. Tiny tap targets are a well-documented problem on mobile, particularly for users with tremors or limited fine motor control.
Accessible Authentication (3.3.8, Level AA) prohibits authentication steps that require cognitive function tests, such as solving a puzzle or transcribing distorted text, unless an alternative is available. This directly addresses CAPTCHAs that are inaccessible to users with certain cognitive or visual disabilities.
Redundant Entry (3.3.7, Level A) requires that users are not asked to re-enter information they have already provided within the same session. Multi-step forms that blank out previously entered data are a common friction point, particularly for users with cognitive difficulties.
Consistent Help (3.2.6, Level A) requires that help mechanisms (a phone number, a chat widget, a contact link) appear in the same location across pages if they appear at all. Predictability matters for users with cognitive disabilities who may struggle to locate support when its position shifts.
Three additional criteria round out the update: Focus Not Obscured at minimum and enhanced levels (2.4.12, 2.4.13) and Accessible Authentication (No Exception) at AAA level (3.3.9). These are genuine usability improvements, not bureaucratic additions. The W3C added them because real users were encountering real barriers that the previous version did not address.
WCAG 2.2 and the Law: ADA, EAA, and Section 508 in Plain English
WCAG is a technical standard, not a law. But multiple laws reference it directly, and knowing which applies to your situation matters.
ADA Title III covers private businesses. There is no government-mandated compliance deadline for web accessibility under Title III. According to ADA.gov guidance, enforcement is lawsuit-driven. Courts handling these cases consistently apply WCAG 2.1 AA as the de facto standard for what “accessible” means. If your site fails WCAG 2.1 AA and someone files a complaint or lawsuit, that is the benchmark they will measure you against. For a deeper look at how ADA enforcement works in practice, the ADA Website Compliance: The Complete 2026 Guide covers the full picture.
ADA Title II covers state and local government entities. The U.S. Department of Justice issued a final rule requiring government websites to conform to WCAG 2.1 Level AA. Compliance deadlines are April 24, 2027 for entities serving populations over 50,000 and April 26, 2028 for smaller entities. This does not apply to private businesses, but it signals the direction of federal enforcement.
The European Accessibility Act (EAA) came into force on June 28, 2025, according to the European Commission. It requires businesses selling products or services in the EU to meet WCAG 2.1 AA standards. The threshold is broad: any company with 10 or more employees or €2 million or more in annual turnover that sells into EU markets. If you have European customers, this applies to you regardless of where your business is incorporated.
Section 508 applies to federal agencies and organisations receiving federal funding. The current required standard is WCAG 2.0 Level AA, with alignment to WCAG 2.1 in progress.
Where does WCAG 2.2 sit in all of this? Ahead of most current legal mandates. The laws reference 2.1. But building to 2.2 now means you will not need to retrofit the new criteria later. The delta between 2.1 AA and 2.2 AA is not large. It is the six new Level A and AA criteria described above. For anyone investing in accessibility work today, 2.2 AA is the right target.
This article is for general informational purposes and is not legal advice.
Your First Five Steps Toward WCAG 2.2 AA Conformance
The 2025 WebAIM Million report found that the average home page has 51 distinct accessibility errors, down from 56.8 in 2024, but still a significant systemic problem. Most of those errors cluster around a small number of fixable issues. Here is where to start.
1. Run an automated scan. Automated tools catch 30 to 40 percent of WCAG failures: missing alt text, low contrast, missing form labels, empty links, and similar. It is not everything, but it is the fastest way to get a baseline picture of where you stand. The Website Accessibility Checker (Free Tool) gives you a breakdown organised by WCAG criteria.
2. Fix your colour contrast. This is the single most common WCAG failure and one of the most fixable. Use a contrast checker to test your body text, headings, and UI elements against their backgrounds. The target is 4.5:1 for text under 18pt and 3:1 for larger text and UI components.
3. Audit your form labels. Every input field needs a programmatically associated label. A placeholder is not a label; it disappears when the user starts typing. Check that each field has a visible, persistent label and that error messages name the specific field and explain what went wrong.
4. Test keyboard navigation. Disconnect your mouse and navigate using only Tab, Enter, and the arrow keys. Can you reach every interactive element? Do menus open? Can you complete your checkout or contact form? Where you get stuck, you have found a real barrier.
5. Check your focus indicators. Tab through your site and watch for the focus ring. If it disappears at any point, or is so faint it is barely visible, that is a WCAG 2.2 failure. The new Focus Appearance criterion (2.4.11) sets a specific minimum size and contrast requirement. Check that your focus styles meet it.
These five steps are achievable in a week without a full audit engagement. They will not get you to complete WCAG 2.2 AA conformance on their own. Manual testing and developer remediation are part of the full picture. But they will surface the highest-impact issues on your site and give you something concrete to hand to your development team.
Once you have worked through them, run the scan again to measure progress against WCAG 2.2 criteria and see what remains.