What Is WCAG? POUR, Conformance Levels, and How It Became EU Law

Someone has told you that your website must "comply with WCAG." Before you can act on that, you need to know three things the instruction leaves out: what WCAG actually is, what "comply" means in a document that has three different conformance levels, and which version of it your regulator is currently entitled to hold you to.

That last question has a different answer this month than most articles on the internet will tell you. We will get to it.

WCAG is a guideline, not a law

The Web Content Accessibility Guidelines are published by the World Wide Web Consortium through its Web Accessibility Initiative. WCAG is a W3C Recommendation - a technical standard produced by a standards body, not a statute produced by a legislature. On its own, it obliges no one.

WCAG becomes binding only where a law or a contract points at it. That indirection matters more than it sounds, because it means two organisations can both be "required to meet WCAG" under completely different terms: different versions, different conformance levels, different scopes, different consequences for falling short. When you are told to comply with WCAG, the useful follow-up question is always under which instrument.

What makes WCAG worth building on regardless is that it is the only widely adopted, testable articulation of what accessible digital content means. Essentially every accessibility law in the world either references it directly or reproduces its substance.

The four-layer structure, and the layer everyone misreads

WCAG is organised as a hierarchy, and knowing which layer you are looking at prevents a specific and expensive mistake.

Layer	Count	Normative?	What it is
Principles	4	Framing	POUR - the top-level qualities accessible content must have
Guidelines	13	Framing	Broad goals under each principle; not directly testable
Success Criteria	87 in WCAG 2.2	Yes	Specific, testable pass/fail statements. This is the layer conformance is measured against
Techniques	Hundreds	No	Documented ways to satisfy a criterion. Informative only

The layer people misread is the last one. Techniques are non-normative. They are examples, not requirements. W3C is explicit that they are informative and that other methods may be used.

In practice, teams routinely treat a documented technique as the mandated implementation - a developer is told a component fails because it does not use the specific ARIA pattern named in a technique document, when in fact any implementation that satisfies the Success Criterion conforms. This wastes remediation budget on rewrites that change nothing for users, and it creates false failures in audit reports. Conformance is measured against Success Criteria and nothing else. If a criterion is satisfied, the method used to satisfy it is your choice.

POUR, with the failure that proves each one

The four principles are a memory aid, not a test. They are useful mainly for explaining to non-specialists why a defect is a defect.

Perceivable - users must be able to take in the information through some sense available to them. Failure: a bar chart showing quarterly results with the figures encoded only in colour and bar height, no text alternative and no data table. A blind user receives nothing; a user with deuteranopia receives something misleading.

Operable - users must be able to drive the interface with whatever input method they have. Failure: a custom dropdown that opens on mouse click but cannot be reached by Tab, so every keyboard-only and switch-device user is stopped at that control.

Understandable - information and behaviour must be comprehensible and predictable. Failure: a form that rejects a submission with the message "Error: invalid input" and no indication of which of eleven fields is wrong or what the expected format is.

Robust - content must work reliably with current and future user agents and assistive technologies. Failure: a modal built from styled div elements with no accessible role, so a screen reader announces nothing and the user has no idea a dialogue has taken over the page.

Conformance levels, and the rules that make them stricter than they look

WCAG defines three levels. They are cumulative: AA includes all of A, and AAA includes all of A and AA.

Level	Character	Typical status
A	Minimum. Removes the most absolute barriers	Rarely sufficient for legal purposes on its own
AA	Addresses the major, common barriers	The near-universal legal target, including in the EU
AAA	Highest. Includes criteria that cannot be satisfied for all content types	Applied selectively, not site-wide

Level AA is what EU law targets. Level AAA is worth understanding mainly so that you do not commit to it: the W3C explicitly advises that AAA conformance is not recommended as a general policy requirement for entire sites, because some AAA criteria are impossible to satisfy for certain kinds of content. Writing "WCAG 2.1 AAA" into a policy or a supplier contract is a common and self-inflicted wound.

Three further rules do more work than the levels themselves:

Conformance is all-or-nothing at the chosen level. You do not score 80% of AA. A page either satisfies every applicable Level A and AA criterion, or it does not conform at AA. There is no partial credit.

Conformance is claimed per page, not per site. A conformance claim attaches to specific URLs. "Our website is WCAG 2.1 AA conformant" is, strictly, a claim about every page in the declared scope - which is why credible statements define their scope precisely rather than gesturing at the whole domain.

Complete processes must conform end to end. If a page is part of a multi-step process - registration, checkout, a benefits application - then every page in that process must conform for any of them to be included in a conformance claim. One inaccessible step in a five-step checkout does not cost you one fifth of your conformance. It invalidates the process.

There is also the "accessibility supported" requirement, which is easy to overlook: to count towards conformance, the technologies you rely on must actually be supported by the assistive technologies your users have. A technically correct ARIA pattern that no shipping screen reader announces is not a pass. This is why real conformance work involves testing with assistive technology and not only with scanners.

How WCAG becomes EU law

The chain has three links, and each one matters if you ever have to defend your position.

1. The European Accessibility Act - Directive (EU) 2019/882 - sets functional accessibility requirements for in-scope products and services. It is written in outcome language and does not name WCAG.
2. The harmonised standard EN 301 549 operationalises those functional requirements into specific, testable clauses for ICT.
3. EN 301 549 incorporates the WCAG Success Criteria for web content, documents and software.

The legal effect of that chain is a presumption of conformity. Where you meet a harmonised standard that the European Commission has cited in the Official Journal of the European Union, you are presumed to conform with the corresponding requirements of the Directive. It is a presumption, not an immunity - but it shifts the burden, and it is the most defensible position available to you.

This is also why "we follow WCAG" is a weaker statement than it sounds in an EU context, and "we conform to the cited version of EN 301 549" is the stronger one.

The version question: what is actually binding right now

Here is where most current commentary is wrong, and where being precise protects you.

On 2 September 2026, ETSI published EN 301 549 v4.1.1. It is a substantial revision: it references WCAG 2.2 Level AA rather than WCAG 2.1, adds six new requirements drawn from WCAG 2.2, removes the obsolete 4.1.1 Parsing criterion, and adds a new Annex ZB and clause A.2 mapping the standard's clauses to the European Accessibility Act.

But v4.1.1 is not yet the legal reference standard. A harmonised standard carries the presumption of conformity only once the European Commission formally cites it in the Official Journal. Until that citation happens, the operative reference remains EN 301 549 v3.2.1 (2021), which is built on WCAG 2.1 Level AA.

So, stated plainly:

• Your current legal floor in the EU is WCAG 2.1 Level AA. Any article telling you WCAG 2.2 is already mandatory under the EAA is ahead of the Official Journal.
• You should nonetheless build to WCAG 2.2 Level AA. It is backwards-compatible - meeting 2.2 AA means you also meet 2.1 AA - and it is unambiguously where the standard is going. Teams that target 2.2 now absorb the change as ordinary delivery work rather than as a remediation project triggered by a citation they do not control the timing of.

The only thing the pending citation changes is when the six additional requirements become enforceable. It does not make them a surprise.

One paragraph on enforcement, because it is no longer hypothetical

EAA enforcement runs through national market surveillance authorities, so both the appetite and the penalty vary by member state. Sweden's PTS has published a list of 200 e-commerce platforms it intends to audit by Q3 2026. Authorities in Germany and the Netherlands have confirmed that enforcement activity is underway and that auditing will expand through 2026. The practical consequence is that a conformance claim is now something you may be asked to substantiate, which is a different standard than something you publish and hope no one reads.

Conformance is the floor, not the goal

It is possible to satisfy all 87 Success Criteria and still ship something people cannot use. WCAG tests discrete, machine-checkable-in-principle properties; it does not test whether a journey makes sense, whether error recovery is tolerable, or whether a task takes a screen reader user four times as long as a sighted user. Those are real accessibility failures that no criterion catches.

This is not an argument for treating WCAG loosely. It is an argument for treating a passing audit as the beginning of the useful work rather than the end of it - and for putting at least some disabled users in front of your product before you conclude it works.

The scale of the problem supports the point. The WebAIM Million 2026 report found detected WCAG 2 failures on 95.9% of the top one million home pages, up from 94.8% the year before - the first reversal after six consecutive years of small improvements. The average page carried 56.1 detected errors. WebAIM attributes much of the regression to rising complexity: the average home page grew to 1,437 elements, a 22.5% increase in a single year. Sites are not getting less accessible because teams stopped caring. They are getting less accessible because they are getting bigger faster than anyone is fixing them.

Where a team new to this should actually start

Not with a scanner. Scanners are step three.

1. Define scope. List the pages and the complete processes in scope, and name them explicitly. Registration, login, checkout, account management, support contact. The process rule means these are your highest-risk surfaces, because a single broken step invalidates the whole flow.
2. Set the target. WCAG 2.2 Level AA, in writing, in your definition of done. Not AAA. Not "WCAG" unqualified.
3. Baseline with both methods. Run an automated scan for breadth, then manual and assistive-technology testing on a representative sample of page types and on every complete process. Automated tooling finds roughly half of the issues by volume and a much smaller share of the criteria; it cannot tell you whether your checkout is usable.
4. Prioritise by user impact, not by error count. A hundred low-contrast decorative labels matter less than one keyboard trap in the payment step. Scanner output is sorted by what is easy to detect, which is not the same as what is blocking people.
5. Put it in the pipeline, not in a project. The WebAIM trend is what happens when accessibility is a periodic clean-up against a codebase that changes weekly. The teams that hold conformance are the ones that gate it in review and in CI.

Then publish an accessibility statement that describes your actual position, including known gaps and how users can report problems. An honest statement with a remediation plan is a far better artefact to hand a market surveillance authority than a conformance claim you cannot evidence.