In short
The Web Content Accessibility Guidelines (WCAG) are the international standard for accessible web content, published by the World Wide Web Consortium (W3C) as part of the Web Accessibility Initiative (WAI). In testable success criteria, they describe when a website can be used by people with disabilities.
In Europe, via the standard EN 301 549, they are the technical yardstick on which laws on digital accessibility are based.
Unlike many standards, the WCAG are not a catalogue of design rules. They prescribe no font size, no colour and no page layout. They define outcomes: that content must be perceivable, that everything must be operable, that language and behaviour must be understandable and that the implementation works with assistive technologies. How you get there remains a question of implementation.
The four principles: POUR
The entire structure of the WCAG rests on four principles summarised under the acronym POUR – perceivable, operable, understandable, robust. Each principle breaks down into guidelines, each guideline into individual, testable success criteria. Anyone who has understood the four principles can classify almost any accessibility defect, even without knowing the number of the criterion.
Perceivable and operable
Perceivable means: every piece of information must arrive via at least one sensory channel available to the user. A product image needs a text alternative, a video subtitles, a status message a form that also works without colour. The contrast requirements belong here too: text must stand out sufficiently from the background. For checking individual colour pairs, the Contrast Checker from WebAIM is suitable; it calculates foreground and background colour directly against the WCAG thresholds.
Operable means: all functions must be reachable, regardless of the input device. The most important test case is the keyboard. Anyone who puts the mouse aside and moves through a page using only Tab, Shift-Tab, Enter and the arrow keys will find most of the serious defects within a few minutes: elements that do not receive focus, focus orders that jump around the layout, overlays you can no longer get out of. Then there are requirements for sufficient time, for avoiding content that can trigger seizures and for comprehensible navigation.
Understandable and robust
Understandable concerns language and behaviour. The language of the page must be marked up technically so that screen readers read aloud correctly. Controls must behave predictably – a selection field that reloads the page unasked when changed violates this principle. And input errors must be identified and, where possible, accompanied by a correction suggestion. The last point in particular decides in forms and checkouts whether an order is placed.
Robust means: the code must be such that current and future assistive tools can interpret it. In practice, this means valid, semantically correct HTML and – where native elements are not sufficient – correctly used ARIA attributes. A div with a click handler is not a button for a screen reader. A real <button> is, with no extra effort. Most robustness problems in practice arise because native elements have been replaced by home-made ones.
What is useful about this division is that it can be mapped onto real usage situations. Behind "perceivable" are blind and visually impaired people, among others, as well as everyone with colour vision deficiency. Behind "operable" are people with motor impairments who do not use a mouse – but also anyone who only has one hand free at the moment. Behind "understandable" are cognitive impairments, learning difficulties and users who do not read the page language as their mother tongue. And behind "robust" is simply the question of whether the technology used works with the assistive tools actually in use. Anyone who can assign a defect to a principle usually already knows whom it affects and how urgent it is.
Conformance levels A, AA and AAA
The WCAG have three conformance levels. They are not quality grades but bundles of success criteria with different depths of intervention.
| Level | Meaning | Practical role |
|---|---|---|
| A | Minimum requirements | Without this level, content is not accessible at all for parts of the user base |
| AA | Extended requirements | The usual legal and contractual yardstick |
| AAA | Highest level | Often not fully achievable for entire websites; the W3C does not recommend it as a general target |
Why AA is the practical yardstick
When WCAG conformance is mentioned in tenders, laws or contracts, level AA is practically always meant. There is a factual reason for this: level A alone leaves gaps that for many users make the difference between laborious and impossible – the stricter contrast values, for example, only belong to AA. Level AAA, in turn, contains criteria that cannot be met sensibly for every type of content; the W3C itself advises against setting AAA as a blanket requirement.
The levels are cumulative: AA includes A, AAA includes A and AA. A statement such as "we meet AA in the most important areas" is therefore not a conformance statement. Conformance always applies to a complete page – a page on which a single success criterion is violated is not conformant, no matter how well the rest has been implemented. That sounds strict, but it is the reason why the claim carries any meaning at all.
Versions: 2.0, 2.1, 2.2 – and a look at 3.0
The WCAG develop in clearly delimited versions that build on each other. Each new 2.x version adopts all success criteria of the previous version and adds more. Anyone who meets WCAG 2.2 AA thereby automatically also meets 2.1 AA and 2.0 AA.
- WCAG 2.0 (2008) – the foundation, still fully contained in all subsequent versions.
- WCAG 2.1 (2018) – additions above all for mobile use, visual impairments and cognitive impairments.
- WCAG 2.2 (2023) – nine additional success criteria, including on focus visibility, target sizes of controls and accessible authentication.
- WCAG 3.0 – in progress, with a fundamentally different evaluation model. No date for completion has been set.
What this means for planning
WCAG 3.0 is occasionally used as an argument for postponing projects – along the lines of: why invest now if everything will soon be different anyway? The argument does not hold. There is no date, the draft is at an early stage, and the transition periods after publication would be considerable. Anyone planning today plans for 2.1 AA as the practical minimum and puts 2.2 on top as the target. The difference between the two is manageable, and building it in from the start is considerably cheaper than retrofitting it later.
The W3C maintains the official status of all versions, including an overview of the documents, on the WCAG overview page of the Web Accessibility Initiative. It is the only source that can be cited on version questions – secondary sources regularly lag behind when the standard changes.
Testing for WCAG: what tools can and cannot do
The most common misjudgement in accessibility projects concerns testing. An automated scan delivers a number, the number looks like the truth, and the project is considered done. In fact, automation only covers some of the success criteria.
The limits of automation
A testing tool can reliably determine whether an alt attribute is missing. It cannot judge whether the existing alternative text describes the image content meaningfully – "image_4711.jpg" passes the automated test and is still worthless. The same applies to focus order, comprehensibility of error messages, a sensible heading hierarchy and the question of whether an ARIA role matches the actual behaviour. How large the machine-testable share is has been investigated by Deque in a report on the coverage of automated accessibility tests.
This is not an argument against tools but one for the right order. Automated testing is excellent as regression protection in the pipeline: it catches the mechanical errors before they go live, with every deploy. The content-related criteria remain manual work – but manual work that does not have to be repeated constantly.
Practical example: the same checkout, three levels of testing
An example from a shop checkout makes this tangible. The automated scan reports two findings: an input field without an associated label and a contrast value of 3.1:1 in the summary of shipping costs. Both are fixed in half an hour.
The manual keyboard test of the same route then finds three more problems that no scan had reported: the payment method dialog opens without taking focus with it, so the keyboard continues to navigate in the background. The dialog's close button cannot be reached via Tab. And the order of the fields jumps back and forth between the columns of the two-column layout, because the visual arrangement via CSS differs from the DOM order.
The final pass with a screen reader finds a fourth: the error message "Please check your entries" is displayed but not marked up as a live region and is therefore not announced. The user only notices it if they happen to navigate there. Not a single one of these four problems would have been noticed without manual testing – and each one may well prevent an order.
WCAG and the legal situation in Germany
The WCAG are not a law. They only become binding because laws refer to them. In Germany, this reference runs for the private sector via the BFSG (Accessibility Strengthening Act), which has applied since 28 June 2025 and implements the European Accessibility Act. Neither the BFSG nor the associated ordinance prescribes a specific WCAG version; the ordinance requires the state of the art to be observed. The practical reference point is the European standard EN 301 549: version V3.2.1, so far only cited in the Official Journal under the Web Accessibility Directive for public sector bodies, builds on WCAG 2.1 level AA, while version V4.1.1, published in September 2026, builds on WCAG 2.2. Under the European Accessibility Act, no version has yet been cited in the Official Journal (as of October 2026).
This construction explains why version questions are legally relevant: the presumption of conformity is not linked to the latest WCAG version but to the version of the standard whose reference has been published in the Official Journal under the EAA. Until then, WCAG 2.1 AA is regarded in practice as the minimum. Anyone who wants to know who exactly is affected, which exceptions apply and which sanctions are threatened will find the answers in the BFSG entry – this entry here describes the technical standard itself.
Why the effort pays off beyond compliance
Finally, a point that almost always gets lost in the discussion of obligations. At their core, the WCAG are good front-end practice in standardised form. Semantically correct HTML, clear focus states, sufficient contrast, understandable error messages, a sensible heading structure – this is not special equipment for a minority but the foundation of an interface that works in general.
The same structure that enables a screen reader to read a page aloud helps search engines and AI systems understand the content. Larger click areas help anyone ordering one-handed on the move. And a checkout that works without a mouse, experience shows, also works more smoothly with a mouse. The effort does not go into a parallel version for special cases but into the same interface that everyone uses.