Sooner or later, anyone who looks into web accessibility meets four letters: WCAG. A web designer says the site "meets WCAG 2.1 AA", a law refers to it, a tender asks for it, a report lists failures against it. WCAG can sound like a thick technical rulebook only specialists can read. In practice, it describes ordinary things: pictures that have a description, text you can read, forms you can fill in with a keyboard, pages that behave as you expect. This article explains what WCAG is, which version and level matter, what changed recently and how to use it without reading the whole thing.
What WCAG is
WCAG stands for Web Content Accessibility Guidelines. It is published by the W3C, the international organisation that develops standards for the web, through its Web Accessibility Initiative (W3C overview). It is free to read and use.
WCAG is built in layers:
- Four principles at the top: content must be perceivable, operable, understandable and robust. More on those below.
- Guidelines under each principle, such as "make text readable" or "give people enough time".
- Success criteria under each guideline. These are the actual requirements, written so they can be tested: a page either meets them or it does not. Each one has a number, such as 1.1.1, and a short name, such as "Non-text Content".
WCAG is not tied to one technology. It describes results, such as "every form field has a label that says what it is for", not how to build them. That is why it works for a hand-written site, a WordPress theme or a page made with an AI builder. Its version 2.2 is also an international standard, ISO/IEC 40500:2025 (W3C announcement).
Versions: 2.0, 2.1 and 2.2
WCAG has grown step by step, and each version adds to the one before.
- WCAG 2.0 (2008) laid the foundation.
- WCAG 2.1 (2018) added requirements for mobile devices, people with low vision and people with cognitive or learning disabilities. Examples are content that works in both portrait and landscape, and text that stays readable when spacing is increased.
- WCAG 2.2 (October 2023) added nine new success criteria, mostly about keyboard focus, touch targets, logging in and help. One old criterion about code syntax, called "Parsing", was removed because modern browsers made it unnecessary (What’s new in WCAG 2.2).
Because the versions build on each other, the W3C designed them so that a site meeting WCAG 2.2 also meets 2.1 and 2.0. If you are starting now, aim for 2.2.
You may also hear about WCAG 3. It is a completely new design that the W3C is still drafting. It is a working draft, not a finished standard, and it will take years before laws refer to it (WCAG 3 introduction). For now, WCAG 2 is what counts.
Levels A, AA and AAA
Every success criterion has a level.
- Level A covers the basics. Without these, some people cannot use the page at all. Examples: images have a text alternative, everything works with a keyboard, there is no keyboard trap (a place the keyboard cannot leave), and videos have captions.
- Level AA adds what makes a site comfortable to use for many more people. Examples: text has enough contrast with its background, pages still work when zoomed to 200%, keyboard focus is visible, and headings and labels describe their topic.
- Level AAA is the strictest. Examples: even higher contrast, sign language for videos and text understandable at a lower-secondary reading level.
The levels add up. To meet AA, a page must meet every A and every AA criterion. In WCAG 2.2 that is 55 success criteria. AAA is a good source of extra ideas, but the W3C itself does not recommend requiring it for whole sites, because some content simply cannot meet every AAA criterion.
When people say "WCAG AA", they mean levels A and AA together. That is the level almost every law and contract asks for.
The four principles with everyday examples
The four principles are easier to remember with the acronym POUR. Each one answers a simple question about your visitors.
Perceivable: can people take in the content?
Information must reach people through at least one sense they can use. A blind visitor hears a screen reader (software that reads the screen aloud), so photos need a short description called alt text. A deaf visitor needs captions on your video. Someone with low vision needs text that contrasts well with the background, and a page that does not break when the text is enlarged. And colour alone is not enough: a form that only shows errors with a red border tells a colour-blind visitor nothing.
Operable: can people use it?
Every function must work in more than one way. Someone who cannot use a mouse moves through your site with the Tab key, so every link, button and menu must be reachable and show where the keyboard is. People who read slowly need enough time, so a session should not expire without warning. Content should not flash more than three times per second, because flashing can trigger seizures. And clear headings and page titles help everyone find their way.
Understandable: can people make sense of it?
The page should speak the visitor’s language, both literally (the page language is set, so a screen reader pronounces words correctly) and figuratively (clear words, short sentences). Pages should behave predictably: a menu stays in the same place, choosing an option does not suddenly send you to another page. Forms explain what they need and, when something goes wrong, say what and how to fix it: "Enter a date like 14/03/2026" helps; "Invalid input" does not.
Robust: does it work with people’s tools?
Your site must work with browsers and assistive technology, today and tomorrow. In practice, this means using real buttons, links and form fields, with names that software can read. A "button" that is only a coloured box responding to a mouse click looks fine, but a screen reader does not announce it and a keyboard cannot reach it.
Which level the law asks for
In the European Union, two laws matter most for websites. The Web Accessibility Directive covers public sector websites and apps. The European Accessibility Act, which applies since 28 June 2025, covers many private services, such as online shops, banking, transport and e-books. Both work through a European standard called EN 301 549. For websites, that standard takes over the WCAG success criteria at levels A and AA.
The version in use today, EN 301 549 V3.2.1, refers to WCAG 2.1 level AA. A new version, V4.1.1, was published in September 2026. It is aligned with WCAG 2.2 level AA and adds a part written specifically for the European Accessibility Act. It becomes the legal reference once the European Commission cites it in the Official Journal of the EU, which is expected around the end of 2026 (Level Access).
National laws build on this. Belgium has the law of 5 November 2023 for the European Accessibility Act, the Netherlands the Toegankelijkheidsbesluit, Germany the BFSG for companies and the BITV 2.0 for public bodies, and France the RGAA, a detailed checklist based on WCAG.
So what should a small business or public body aim for? WCAG 2.1 AA is what the law asks today. WCAG 2.2 AA contains everything in 2.1 AA (apart from the removed Parsing criterion) plus six new criteria, and it is where the law is heading. If you are building or rebuilding a site, aim for 2.2 AA so you do not have to revisit it soon.
What changed in WCAG 2.2 that matters for small sites
Six of the new criteria are at level A or AA. Each fixes something people run into every day.
- Focus not obscured. When you move through a page with the keyboard, the item you are on must not be completely hidden behind a sticky header, a chat button or a cookie banner.
- Target size. Buttons and links you tap must be at least 24 by 24 pixels, or have enough space around them, so people with shaky hands do not hit the wrong one. Links inside a sentence are an exception.
- Dragging movements. Anything that needs dragging, such as a slider, a map or reordering items, must also work with simple clicks or taps.
- Consistent help. If you offer help, such as a phone number, a contact link or a chat, put it in the same place on every page.
- Redundant entry. Do not ask people to type the same thing twice in one process. If a customer entered their address in step one, fill it in or let them select it in step three, for example with a "Same as delivery address" checkbox.
- Accessible authentication. Logging in must not depend on remembering or retyping something without help, or on solving a puzzle. Allow copy and paste and password managers, or offer a login link by email. Image-recognition puzzles and personal content are allowed exceptions at level AA, but simpler options are kinder.
Two of these are often fixed with a few lines of CSS (the code that controls how a site looks):
/* Keep focused items visible below a sticky header 80px high */
html {
scroll-padding-top: 80px;
}
/* Give small icon buttons a comfortable tap area */
.icon-button {
min-width: 44px;
min-height: 44px;
}And the most common login problem is a password field that blocks pasting:
<!-- Avoid: blocks password managers and pasting --> <input type="password" onpaste="return false" /> <!-- Better: lets password managers fill the field --> <input type="password" autocomplete="current-password" />
How to use WCAG without reading all of it
You do not need to read the full standard. A few habits get you most of the way.
- Start from your visitors’ main tasks. Finding information, booking, paying, contacting you. Check that each task works, rather than checking each criterion in the abstract.
- Use the W3C’s quick reference. How to Meet WCAG lists every criterion with short explanations and examples, and lets you filter by level. Filter on A and AA and hide the rest.
- Fix the common problems first. In WebAIM’s 2026 analysis of one million home pages, the most frequent failures were low-contrast text, missing image descriptions, form fields without a label, empty links, empty buttons and a missing page language (WebAIM Million). Our repair guides cover each of these.
- Read the "Understanding" page when in doubt. Each criterion has a page explaining its intent, who it helps and examples. Your developer will find the technical techniques there.
- Put it in writing. When you hire a designer, developer or agency, or choose a theme, ask for "WCAG 2.2 level AA" explicitly, and ask how they test it.
- Write it down in a statement. An accessibility statement says which standard you follow, what you checked and what still needs work. Our statement guide explains how.
How automatic checks relate to WCAG
Automatic checkers, including ibin, test pages against the WCAG success criteria that software can reliably assess. Is there a text alternative at all? Does text have enough contrast? Does each field have a label? Is the page language set? These checks are fast and repeatable, and they catch many of the most common failures.
But many criteria need a person. Software can see that an image has alt text, but not whether "photo123" or "image" describes it. It can check that a page has headings, but not whether they describe the content. It cannot tell whether your instructions are clear or whether a menu really works with the keyboard. Automatic checks find roughly a third to half of the problems; people check the rest.
A good routine combines both. Run an automatic check, fix what it finds, then do the ten-minute keyboard test and read your image descriptions and link texts with fresh eyes. ibin’s optional second look from AI rates image descriptions, link texts and keyboard use, among others, so you know where to look first. These are leads, not verdicts. And no tool can certify that a site meets WCAG: that takes a full review by people.
Check a page against the basics
Check a page for free with ibin to see which WCAG problems the automatic checks find, explained in plain language, with a picture of where each problem is and a guide to fix it. Start with your home page or your most important form, fix the critical problems first, and check again.
See how your own site does
Check a page for free, without an account. You get a plain list of what to fix first, with pictures of where each problem is.
