What is WCAG?

This guide explains what WCAG actually covers, which level and version apply to you, and how to find out where your website stands. It draws on the standard itself, guidance from Digg, and what we see when we audit and build websites.

WCAG, Web Content Accessibility Guidelines, is the international standard for accessible web content. It is developed by W3C, the organisation behind the web’s technical standards, and sets out testable requirements that a website or app must meet to work for people with disabilities — including visual, hearing, motor and cognitive impairments.

The current version is WCAG 2.2. Since 2025, it has also been an ISO standard, ISO/IEC 40500:2025. In Sweden and the rest of the EU, WCAG Level AA is, in practice, the benchmark used to assess legal compliance through the European standard EN 301 549.

WCAG is developed by a working group within W3C’s Web Accessibility Initiative. This is the same organisation that standardises HTML and CSS, which is why WCAG has become the benchmark almost everywhere that digital accessibility is required by law.

The fact that WCAG 2.2 was approved as ISO/IEC 40500:2025 in October 2025 changes nothing in substance — the content is exactly the same as W3C’s October 2023 version. But it makes it easier for more countries and procuring organisations to reference the standard formally.

For you, this means one thing: WCAG is not an agency’s interpretation or an industry recommendation. It is an open, free standard that both you and your supplier can read and check against.

WCAG 2.2 has three layers: four principles, 13 guidelines beneath them, and 86 success criteria beneath the guidelines. The success criteria determine whether a website meets the standard. The principles and guidelines provide the structure that makes them easier to understand.

The four principles:

• Perceivable. All content must be accessible through more than one sense. Images have text alternatives, videos have captions, and text has sufficient contrast against its background.
• Operable. Everything must work with a keyboard and assistive technology, not just a mouse or a finger. No function should require precise movements or impose a time limit that cannot be switched off.
• Understandable. Language, navigation and forms must be predictable. Form errors must be explained so that users understand how to correct them.
• Robust. Code must be written so that browsers and assistive technologies such as screen readers can interpret it correctly, including future versions.

Each success criterion is written as a testable statement. For example, normal text must have a contrast ratio of at least 4.5:1 against its background, and large text at least 3:1. The page either meets that requirement or it does not.

The success criteria are divided into three levels. Each builds on the previous one — to meet AA, you must also meet every Level A requirement.

• Level A is the foundation, with 31 criteria in WCAG 2.2. Failing to meet them excludes some users entirely. A button that cannot be reached using a keyboard is a typical Level A failure.
• Level AA adds 24 criteria, bringing the total to 55. This is the level used in legislation and most public procurement requirements. The contrast requirement above sits at this level.
• Level AAA adds another 31. W3C itself advises against requiring AAA for an entire website, because some types of content cannot meet all AAA criteria.

In practice, then, AA is the level that matters. When a supplier writes "WCAG-compliant" without specifying a level and version, it tells you very little.

The versions build on one another. The requirements in 2.0 still apply, and each new version adds criteria.

• WCAG 2.0 was published in December 2008 with 12 guidelines.
• WCAG 2.1 was published in June 2018 and added one guideline and 17 criteria, mainly addressing mobile use, low vision and cognitive needs. That brought the total to 78 criteria.
• WCAG 2.2 was published in October 2023 and added nine criteria. One older criterion, 4.1.1 on parsing, was removed because browsers and assistive technologies no longer depend on it.

The nine new criteria in 2.2 address issues that are still common: focus indicators must not be hidden behind fixed headers or cookie banners; clickable targets must be at least 24 × 24 pixels; drag-and-drop actions must also be possible with simple clicks; users should not have to enter the same information twice; and signing in must not require users to remember or transcribe something without an alternative.

A website that meets WCAG 2.2 also meets 2.1 and 2.0. So our advice is simple: build to 2.2 AA now, even if you are still reporting against 2.1.

WCAG is not a law. But two Swedish laws use WCAG as their benchmark through the European standard EN 301 549.

• The Swedish Digital Public Services Accessibility Act, known as the DOS Act, has applied since 2019 to government agencies, municipalities, regions and certain publicly funded organisations. Digg states that the requirements are met by following EN 301 549 V3.2.1, which is based on WCAG 2.1 Level AA.
• The Swedish Accessibility Act, which implements the European Accessibility Act, came into effect on 28 June 2025. It applies to private companies offering certain products and services to consumers, including e-commerce and banking services. In practice, the technical requirements are at the same level.

A new version of EN 301 549 has recently been published. According to W3C, the 2026 version is based on WCAG 2.2. It will only become the legal benchmark once the EU formally designates it; until then, WCAG 2.1 AA applies. That is another reason not to build anything new to a standard below 2.2 AA.

We cover who is affected, what exemptions exist and which authorities oversee compliance in The European Accessibility Act 2025: what the law actually requires of you.

The errors are surprisingly predictable. Every year, WebAIM scans the homepages of one million websites using automated tools. In the February 2026 survey, 95.9 per cent had WCAG errors, with an average of 56 per page. Six types of error accounted for 96 per cent of everything found:

• Low-contrast text — on 83.9 per cent of pages
• Images without alternative text — 53.1 per cent
• Form fields without labels — 51 per cent
• Empty links — 46.3 per cent
• Empty buttons — 30.6 per cent
• Pages with no declared language — 13.5 per cent

The same six have topped the list for seven years. That tells us something important: the problem is rarely that the requirements are difficult. It is that no one is checking them.

We see the same pattern in our own audits, with two additional issues that automated testing misses: custom-built components such as menus, modals and carousels that cannot be used with a keyboard, and brand colours that were never tested against contrast requirements before being signed off.

An automated tool gives you a useful first overview, but it is not enough. It can detect low contrast and missing alt text. It cannot judge whether alt text describes the image, whether the tab order makes sense, or whether an error message is understandable.

A reliable audit therefore has four parts:

1. Automated scanning of a representative sample of pages — the homepage, templates, forms, checkout or booking flow.
2. Manual testing using only a keyboard, and with a screen reader for the most important user journeys.
3. A content review, because accessibility is affected every time someone publishes an image, PDF or video.
4. A prioritised action list linked to the relevant success criteria, not just a score.

The findings should then be included in your accessibility statement, which sets out what meets the requirements and what still needs work.

The most cost-effective approach is to include the requirements from the start. When we build websites, we test colours and contrast during the design phase, design components for keyboard use from the outset, and write semantic code — using ARIA only where standard HTML is not enough. Fixing things afterwards almost always costs more.

W3C is working on a successor, WCAG 3, with a new structure and a new way of assessing conformance. It is still a draft and is not expected to become a finished standard for several years. WCAG 2 will not be replaced until several years after that.

W3C’s own advice is clear: the best way to prepare for WCAG 3 is to meet WCAG 2.2 today.

Read about our approach to accessibility and WCAG, or download our guide to accessible websites.

• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C, Recommendation, 12 December 2024. Checked 2 October 2026.
• WCAG 2 Overview — W3C WAI. Versions, ISO/IEC 40500:2025 and EN 301 549. Checked 2 October 2026.
• What's New in WCAG 2.2 — W3C WAI. Checked 2 October 2026.
• WCAG 3 Introduction — W3C WAI. Checked 2 October 2026.
• Digital accessibility — Digg, Agency for Digital Government. Checked 2 October 2026.
• The WebAIM Million, 2026 — WebAIM, February 2026 survey. Checked 2 October 2026.

This article is for information only and does not constitute legal advice. To assess whether and how the law applies to your organisation, consult a qualified legal adviser.