A practical guide to WCAG 2.2

What WCAG is, and the A, AA, AAA levels

WCAG stands for the Web Content Accessibility Guidelines. It is the internationally recognized reference for making websites usable by people with disabilities, and it is what laws like the ADA and EN 301 549 point to in practice. The current version is WCAG 2.2.

WCAG is organized into success criteria, and each criterion sits at one of three levels. Level A is the minimum, the things that block people outright if you miss them. Level AA is the common target for most sites and the level most legal frameworks expect. Level AAA is the highest bar and is not usually required across a whole site.

• A: essential. Missing these makes content unusable for some people.
• AA: the practical target most organizations aim for.
• AAA: aspirational, applied to specific content rather than everywhere.

The four principles

Every WCAG criterion supports one of four principles, often remembered by the initials POUR. They are a useful way to think about accessibility even before you read a single success criterion.

Here is what each one means in plain terms, with an everyday example.

• Perceivable: people can take the content in. Example: images have text alternatives so a screen reader can describe them.
• Operable: people can use the controls. Example: every menu and button works with a keyboard, not just a mouse.
• Understandable: content and behavior make sense. Example: form errors say what went wrong and how to fix it.
• Robust: it works with the tools people use. Example: your markup is clean enough for assistive technology to read reliably.

The most common failures

Across audits, the same handful of problems show up again and again. If you fix these, you resolve a large share of real world barriers before touching anything more subtle.

None of these require a redesign. Most are small, specific fixes in your content and markup.

• Missing alt text: images without a text alternative, so screen reader users get nothing.
• Low contrast: text that is too close in color to its background to read comfortably.
• Keyboard access: menus, sliders, and pop ups that only respond to a mouse.
• Form labels: inputs with no associated label, so people cannot tell what to type.
• Heading structure: pages with no headings or skipped levels, which makes navigation hard.

What changed in WCAG 2.2

WCAG 2.2 builds on 2.1 and adds new success criteria, most of them aimed at people with motor and cognitive disabilities. Nothing from 2.1 was removed, so meeting 2.2 also means you meet the earlier version, with one criterion retired for being hard to apply.

The additions are practical. They cover things like making sure a keyboard focus indicator is actually visible, not hiding the element someone is interacting with behind a sticky header, keeping drag actions from being the only way to do something, and not forcing people to remember or re-enter information they already gave you.

• Visible focus that is not obscured by other content.
• Alternatives to dragging and to complex gestures.
• Consistent placement of help links across pages.
• Not making people re-enter or memorize information unnecessarily.

How automated tools and manual testing fit together

Automated tools are genuinely useful, but they are only part of the picture. Realistically, automated checks catch somewhere around 30 to 40 percent of accessibility issues: the things a machine can measure, like a missing alt attribute or a contrast ratio.

The rest needs a human. Whether alt text is meaningful, whether the keyboard order makes sense, whether an error message is actually helpful, these are judgment calls. The strongest approach uses automated scans to find the obvious problems fast, then manual testing, including testing with a keyboard and a screen reader, for everything else.

• Use automation to catch measurable issues quickly and continuously.
• Test with a keyboard: can you reach and use everything without a mouse?
• Test with a screen reader to hear how the page is announced.
• Include people with disabilities in testing when you can.

Where a widget helps, and where it does not

An accessibility widget like ClearPath gives visitors tools to adapt your site to their needs: adjusting contrast, resizing text, pausing motion, and switching on reading aids. That is real, immediate help for many people, and it supports your effort to work toward WCAG 2.2, ADA, and EN 301 549 goals.

A widget does not replace fixing the underlying code, though. If an image has no alt text or a form field has no label, that has to be corrected in the site itself. Think of the widget as a strong layer on top of accessible foundations, not a substitute for building them. It helps you work toward compliance goals, it does not guarantee compliance on its own.

The four principles, in plain terms

Every WCAG success criterion sits under one of four principles, usually shortened to POUR. They are worth knowing because they tell you what kind of problem you are looking at before you go hunting for a rule number.

• Perceivable: people can take the content in. Text alternatives for images, captions for video, enough colour contrast, content that still works when text is resized.
• Operable: people can drive the interface. Everything reachable by keyboard, no traps, enough time to finish tasks, nothing that flashes in a way that can trigger seizures.
• Understandable: people can follow it. Predictable navigation, clear labels, errors that say what went wrong and how to fix it.
• Robust: assistive technology can read it. Valid names, roles and values, so a screen reader announces a control as what it actually is.

A, AA and AAA: which level you are actually aiming for

WCAG grades criteria at three levels. Level A is the floor, level AA is the level nearly every law and contract points at, and level AAA is a stretch that the guidelines themselves say is not achievable for all content.

In practice, when a regulator, a customer or a tender says WCAG, they mean 2.1 or 2.2 at level AA. That is the target to plan for. Chasing AAA on everything is not a good use of a small team.

What WCAG 2.2 added, criterion by criterion

WCAG 2.2 became a W3C Recommendation in October 2023. It is backward compatible: meeting 2.2 means you also meet 2.1. It added nine success criteria and removed one, 4.1.1 Parsing, which modern browsers and assistive technology made obsolete.

• 2.4.11 Focus Not Obscured (Minimum, AA): when something has keyboard focus, a sticky header, cookie bar or chat bubble must not completely hide it.
• 2.4.12 Focus Not Obscured (Enhanced, AAA): the focused item must not be hidden at all.
• 2.4.13 Focus Appearance (AAA): the focus indicator has to be big enough and have enough contrast to actually notice.
• 2.5.7 Dragging Movements (AA): anything you can do by dragging must also work with a single pointer action, for example a sortable list that also has move up and move down buttons.
• 2.5.8 Target Size (Minimum, AA): interactive targets are at least 24 by 24 CSS pixels, or spaced far enough apart to be safe to hit.
• 3.2.6 Consistent Help (A): if you offer help, contact details or a chat, put it in the same place on every page.
• 3.3.7 Redundant Entry (A): do not make people retype information they already gave you earlier in the same process.
• 3.3.8 Accessible Authentication (Minimum, AA): do not force a cognitive test such as remembering a puzzle or transcribing characters. Allow paste, password managers and other simple routes in.
• 3.3.9 Accessible Authentication (Enhanced, AAA): the same, with fewer exceptions.

How to test your own site in an afternoon

You do not need a lab. Most real problems surface with four passes that anyone on the team can run.

• Keyboard only: unplug the mouse. Tab through a full task, for example search, add to cart, checkout. Watch for focus you cannot see, focus that jumps somewhere odd, and anything you can enter but not leave.
• Zoom and reflow: set the browser to 200 percent, then to 400 percent at a narrow width. Content should reflow into one column without horizontal scrolling or overlapping text.
• Contrast: check body text, placeholder text, disabled states and text over images. The AA bar is 4.5 to 1 for normal text and 3 to 1 for large text and interface components.
• Screen reader: open the page with VoiceOver, NVDA or Narrator and listen to the first minute. Unlabelled buttons, images announced as their filename, and headings that skip levels all become obvious fast.

The failures we see most often

• Form inputs with a visual label that is not connected to the field, so the screen reader announces nothing useful.
• Icon only buttons with no accessible name, announced as just button.
• Custom dropdowns, modals and carousels built from divs, which look fine and are unusable by keyboard.
• Alt text that describes the file rather than the content, or decorative images given long descriptions nobody needs.
• Colour used as the only signal, for example a red border marking an invalid field with no message.
• Focus indicators removed in CSS because they were considered ugly.

Where a widget fits, and where it does not

A widget like ClearPath sits on top of your pages and lets a visitor turn on the adjustments they need: more contrast, larger text, wider spacing, a visible focus outline, a reading guide, a screen reader. That is real help, and it arrives the day you install it.

It does not rewrite your markup. Missing form labels, a keyboard trap in a custom component, heading levels in the wrong order and meaningless alt text all live in your code, and they are exactly what an audit or a complaint tends to be about. Treat the widget as the layer that helps people today while the code work happens in parallel.