WCAG 2.2, explained for agencies

What WCAG is

The Web Content Accessibility Guidelines are published by the World Wide Web Consortium (W3C). They are a technical standard, not a law, and nobody enforces WCAG directly. What happens instead is that legislation points at it.

In the EU, the European Accessibility Act relies on the harmonised standard EN 301 549, and for web content EN 301 549 points at WCAG at level AA. So the chain runs: national law → EU directive → EN 301 549 → WCAG. By the time a client asks “what do we actually have to do”, the answer is a list of WCAG success criteria. The legal chain in full.

WCAG is organised as four principles, a set of guidelines under each of them, and a numbered list of success criteria. The success criteria are the testable part: each one is a statement that is either true or false for a given page.

The four principles

Everything in WCAG hangs off four words. They are worth learning because they are the fastest way to explain a finding to a client who does not care about criterion numbers.

Perceivable

The user has to be able to take the information in through some sense. Alternative text for images, captions for video, enough contrast between text and its background, structure that survives when the styling does not.

Operable

The user has to be able to drive the interface. Everything reachable and usable with a keyboard, no traps, enough time to complete a task, controls large enough to hit, a way to skip repeated navigation.

Understandable

The content and the interface have to make sense. A declared page language, predictable navigation, labels that say what a field wants, and error messages that say what went wrong and how to fix it.

Robust

The page has to work with the software people use, including assistive technology. Every control exposes a name, a role and its current state — which is what a screen reader reads out.

Levels A, AA and AAA

Each success criterion carries a level, and the levels are cumulative:

• Level A — the floor. Failing one of these usually means some group of users cannot use the feature at all: an image with no alternative text, a control that cannot be reached with a keyboard.
• Level AA — the level regulations reference, including EN 301 549 and therefore the EAA. It includes everything in level A, plus criteria such as minimum colour contrast, text resizing and consistent navigation.
• Level AAA — a further, more demanding set. The W3C itself does not recommend AAA as a general policy for entire sites, and the EAA does not require it. Rampsight does not test it: putting AAA findings in a compliance report inflates the problem with things nobody is asking for.

“WCAG AA” in a tender document therefore means all of level A and all of level AA.

WCAG 2.0, 2.1 and 2.2

There are three versions of WCAG 2 in circulation, and they are additive rather than competing. Later versions add success criteria; they do not rewrite the earlier ones.

• WCAG 2.0 became a W3C Recommendation on 11 December 2008. It is the base that older regulations reference.
• WCAG 2.1 followed on 5 June 2018, adding one guideline and 17 success criteria — largely mobile, low vision and cognitive accessibility. This is the version EN 301 549 currently references for web content, at level AA.
• WCAG 2.2 became a Recommendation on 5 October 2023, adding 9 success criteria — among them Focus Not Obscured, Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry and Accessible Authentication. One older criterion, 4.1.1 Parsing, is obsolete and removed in 2.2.

The W3C states that content conforming to WCAG 2.2 also conforms to WCAG 2.1 and WCAG 2.0. That is why Rampsight tests against WCAG 2.2 at levels A and AA: it covers the WCAG 2.1 AA baseline that EN 301 549 references today, and it does not leave your clients re-testing the day the standard reference moves.

What an automated tool can and cannot check

This is the honest part, and it is the part most vendors skip. Rampsight runs the axe-core engine in a real browser against every page it crawls, restricted to the WCAG A and AA rules. Automated testing covers a real but partial share of the success criteria.

What a scan reliably finds

The machine-verifiable facts — the ones where the answer is in the markup or in a computed value:

• Missing alternative text on images and image buttons.
• Contrast ratios below the threshold, computed from the rendered colours.
• Form fields, buttons, links and frames with no accessible name.
• A missing or invalid page language.
• Invalid or unsupported ARIA: attributes a role does not allow, required attributes that are absent, values that are not legal.
• Structural markup that is broken — lists that are not lists, data tables whose headers point nowhere.
• Zooming disabled in the viewport meta tag.
• Touch targets below the minimum size.

What only a person can judge

• Whether alternative text is any good. A tool sees that alt exists. It cannot see that alt="image" on a product photo tells a buyer nothing.
• Whether a custom widget actually works. A hand-built date picker or modal can carry perfect ARIA and still trap focus or announce nonsense.
• Reading and focus order. Whether tabbing through the page follows the visual order, and whether focus goes somewhere sensible after a dialog closes.
• Whether link text makes sense out of context. Twelve links all reading “read more” pass every automated check.
• Whether error messages help. “Invalid input” is announced correctly and is still useless.
• Media. Whether captions match the audio, whether an audio description exists and describes the right things.

The practical consequence: a scan is how you find the hundreds of mechanical failures fast and cheaply, so the expensive human review starts from a site that is already fixed in the obvious places. It is not a substitute for that review, and a clean scan is not a conformance claim.

Using this with a client

1. Set the target as “WCAG 2.2, levels A and AA”. It is the level regulations reference, and stating the version avoids the argument later.
2. Baseline the site. A scan of 100 to 1000 pages, depending on the plan, gives you a score, a grade and a list of located failures on day one.
3. Fix by severity and reach first. A contrast failure in the global header outranks a rare one on a single page. Fixing the component fixes every page at once.
4. Then commission the human pass for keyboard operation, screen reader behaviour and content quality — the criteria on the second list above.
5. Publish an accessibility statement that says honestly what conforms and what does not yet. What it must contain.
6. Keep scanning on a schedule, because the next release is what breaks it.