What are the WCAG

WCAG stands for Web Content Accessibility Guidelines. They are published by the W3C through its Web Accessibility Initiative (WAI). What sets them apart from any book of best practice is verifiability: every requirement is worded so that two independent auditors reach the same verdict about the same screen.

Three layers that get mixed up in practice are worth separating. Web accessibility is the property of the site. The WCAG are the yardstick that measures that property. And the law decides who is required to meet it and from when. The W3C neither legislates nor sanctions: it writes the yardstick, and European and national rules then adopt it by reference. Arguing about «whether the WCAG are mandatory» conflates all three layers.

The nominal scope is web content, meaning whatever is delivered to the browser and can be interpreted by assistive technology. Native mobile apps, desktop software and office documents fall outside the literal text, although the European reference standard and much of public procurement assess them by analogy against the same criteria.

There is a second limit that is often misunderstood. The WCAG prescribe neither a particular design nor a particular component. They describe required outcomes rather than implementations, which is why the same screen allows several equally conformant solutions.

The hierarchy has three tiers. At the top, four principles: perceivable, operable, understandable and robust. Below them, thirteen guidelines that group thematic objectives such as contrast, keyboard navigation or help with data entry. At the operational level sit the success criteria, the statements that are actually audited. The numbering reflects this: criterion 1.4.3 belongs to principle 1, guideline 4, and is the third of that guideline.

Each criterion carries a level. Version 2.2 numbers 86 criteria: 31 at level A, 24 at level AA and 31 at level AAA. The levels are cumulative, so declaring AA also requires meeting the level A criteria, 55 in total. AAA is not intended as a blanket target for a whole site, because some content types make it unreachable.

Declaring conformance also requires five conditions that are routinely overlooked: you declare a full level, for full pages, for complete processes such as a purchase or a sign-up, using only accessibility-supported technologies, and without any non-conformant part interfering with the rest of the page. A page that fails a single criterion is not conformant, however many others it passes.

As for versions, 2.0 (2008) set 61 criteria, 2.1 (2018) added 17, and 2.2 (October 2023, with an editorial update in December 2024) added nine more and removed 4.1.1 «Parsing», which became obsolete. Version 3.0 remains a working draft with no normative force. The European standard EN 301 549, the one cited in regulation and in tenders, adopts WCAG 2.1 level AA in its harmonised version, and its revision towards 2.2 is under way.

The decision that depends on the WCAG is not whether to make a site accessible, but how the budget splits between automated tooling and human review. That is where most accessibility plans break.

The most useful figure on that split comes from an audit by the UK Government Digital Service: the team introduced 142 accessibility barriers into a page and ran it through thirteen automated tools; the best one detected 40 % of the problems introduced. What remains requires human judgement. Whether an alternative text describes the image or merely repeats the file name, whether focus order follows the visual logic, whether an error message explains how to fix the entry: no scanner settles that.

Two practical consequences follow. An automated report with no findings is not a conformance claim but a filter that has removed the crudest failures. And the target level, almost always AA, is set at the start of the project, because criteria such as minimum contrast or target size shape the design system; fixing them at the end costs a redesign rather than a patch.

• Put the target level (A plus AA) and the specific version in writing before design work starts, and include it in the tender or the agency contract.
• Audit complete processes rather than isolated pages: sign-up, search, cart, checkout and password recovery, error states included.
• Combine an automated scanner with a minimum manual review: a full keyboard-only run, a screen reader test and a check of zoom at 200 %.
• Turn contrast, target size and the focus indicator into design system tokens, so every new component satisfies them by default.
• Publish an accessibility statement with the standard version, the level reached, the evaluation date, the method used and a contact route for reporting barriers.
• Record every known failure with its cause and its planned fix date, instead of leaving it out of the report.

• Treating «zero errors in the scanner» as proof of conformance, when the automatable share of the criteria is a minority.
• Installing an overlay and considering the matter closed. The Overlay Fact Sheet, signed by specialists and organisations in the field, holds that an overlay cannot achieve full conformance because it does not repair every type of failure, and further warns that detecting a user's assistive technology exposes sensitive personal information.
• Setting AAA as a blanket site policy and ending up with no statement at all, instead of sustaining AA.
• Auditing the design mock-up rather than the live site with real data, filled forms, open modals and JavaScript-loaded content.
• Treating accessibility as a final QA phase, when the costliest criteria are decided in the design system and in the markup.