WCAG 2.1 AA explained: what the standard asks, and how I build and test to it

The point: WCAG is the standard, and AA is the line the laws draw

WCAG stands for the Web Content Accessibility Guidelines. It is the technical standard that says what makes a website, a web app or a document usable by people with disabilities, and it is the standard almost every accessibility law in Europe points at.¹ If you have read that your shop or your SaaS has to be accessible, the law tells you that you must comply and by when. WCAG tells you what "accessible" actually means, line by line, and gives you something you can test against.

I keep this article on the standard and on the practice: what WCAG asks, how you meet it, and how you prove it. The question of who must comply, and from what date, belongs to the law, and I cover that separately in my article on accessibility law for online businesses. The two fit together. The law sets the duty, WCAG 2.1 at Level AA sets the bar, and this piece is about clearing it.

One honesty point up front, because it runs through everything below. WCAG is a standard published by a standards body, not a certificate issued by anyone. There is no badge to buy and no stamp that makes you compliant. You build to the standard, you test against it, and if you want independent assurance, an accessibility auditor evaluates the result. So the honest claim is "built and tested to WCAG 2.1 AA", never "guaranteed compliant". I will come back to why that wording matters.

Who publishes WCAG, and why there are versions

WCAG is published by the World Wide Web Consortium, the W3C, through its Web Accessibility Initiative and the Accessibility Guidelines Working Group.¹ The same body that standardises HTML and CSS standardises how accessible content should behave, which is one reason WCAG has become the common reference for regulators.

There are three versions in use, and the numbers matter.

WCAG 2.0 was published on 11 December 2008.¹ It defined the structure that everything since has kept: four principles, testable success criteria, and three conformance levels.

WCAG 2.1 was published on 5 June 2018, and the current edition is dated 6 May 2025.¹ It kept all of WCAG 2.0 and added 17 success criteria, mostly to cover mobile devices, low vision and cognitive needs that the 2008 version did not address well.² This is the version most European laws reference today.

WCAG 2.2 was published on 5 October 2023.¹ It adds nine further success criteria, among them target size for touch, consistent help, and an authentication criterion that lets people avoid cognitive tests such as remembering and transcribing a code.³ It also retired one older criterion, 4.1.1 Parsing, which modern browsers made redundant.³ WCAG 2.2 is backward compatible: content that meets 2.2 meets 2.1, so building to 2.2 is a safe way to stay ahead.

My practical advice is simple. Build to WCAG 2.1 AA because that is what the law points at, and pick up the nine WCAG 2.2 additions where you can, because they are genuine improvements and because the legal references will move to 2.2 in time. Nothing in 2.2 undoes 2.1.

The four principles, or POUR

WCAG organises everything under four principles. Content must be perceivable, operable, understandable and robust, which is why people shorten the set to POUR.⁴ Every success criterion sits under one of them, so the principles are the map.

Perceivable means a person can take the information in through whatever sense works for them. If content is only available one way, someone who cannot use that way is locked out. In practice this is text alternatives for images, so a screen reader can announce an alt description instead of an empty graphic (success criterion 1.1.1).⁴ It is captions for video and an audio description track for the visual content (1.2.2 and 1.2.5).⁴ It is enough colour contrast, which I come to under the levels below. And it is not using colour alone to carry meaning, so a form field marked only by turning red still tells a colour blind user what is wrong (1.4.1).⁴

Operable means a person can actually drive the interface. The headline test is the keyboard: everything you can do with a mouse must work from the keyboard alone, because many assistive tools present themselves to the page as a keyboard (2.1.1).⁴ A close partner to that is no keyboard trap, meaning focus must never get stuck somewhere a keyboard user cannot leave (2.1.2).⁴ Operable also means a visible focus indicator, so a keyboard user can see where they are (2.4.7), and a sensible focus order that follows the meaning of the page (2.4.3).⁴

Understandable means people can make sense of the content and of the interface. Set the page language so a screen reader uses the right pronunciation (3.1.1).⁴ Label form fields clearly and give instructions where they are needed (3.3.2).⁴ When something goes wrong, identify the error in text and, where you can, suggest how to fix it (3.3.1 and 3.3.3).⁴ A card number rejected with a bare red border fails this; "Card number must be 16 digits" passes it.

Robust means the content keeps working across browsers and assistive tools, now and as they change. The core criterion here is name, role and value: every interface component must expose what it is, what it does and its current state to assistive technology (4.1.2).⁴ A <button> element gets this for free. A <div> you have styled to look like a button does not, unless you add the right role and keyboard handling, which is why native HTML elements save so much trouble.

Conformance levels: A, AA and the reason AA is the target

WCAG grades its success criteria into three levels: A, AA and AAA.⁴ They are not three separate checklists. AA includes everything in A, and AAA includes everything in A and AA. So conforming at Level AA means satisfying every Level A criterion and every Level AA criterion.⁴

Level A is the floor. It catches the failures that lock people out completely: no keyboard access, images with no text alternative, video with no captions at all. A site that only meets Level A is not usable enough, and no serious law stops at A.

Level AA is the working target. It adds the criteria that make a site genuinely usable rather than merely operable: adequate colour contrast, text that resizes, content that reflows on a small screen, labels and error handling that hold up. This is the level the European Accessibility Act and the public sector rules across Europe reference, and the level I build to by default.¹

Level AAA is the most demanding, with criteria such as a 7:1 contrast ratio and sign language interpretation for video. The W3C itself says it does not recommend AAA as a requirement for whole sites, because some AAA criteria cannot be met for all content.⁴ You might meet individual AAA criteria where they are easy and valuable, but you do not promise AAA across a product.

The reason AA is the target is that it is the point where a site works for the large majority of people using assistive technology, and it is achievable across an entire site, which AAA is not. When the law says "accessible", AA is what it means.

A note on size, because it reassures people. WCAG 2.1 has 78 success criteria in total, the 61 from WCAG 2.0 plus the 17 added in 2.1.² Meeting AA does not mean meeting all 78. It means meeting the Level A and Level AA ones, and many of those are a single, well made decision that then covers the whole site, such as using proper headings, labelling your forms, and choosing an accessible colour palette once.

How you actually test it: automated tools find only part

Here is the most important practical truth in this article, and the one most often got wrong. An automated accessibility scanner cannot tell you whether you meet WCAG. It can only find a slice of the problems.

The W3C is blunt about this. Its guidance on choosing evaluation tools states that "tools cannot check all accessibility aspects automatically" and that "web accessibility evaluation tools can not determine accessibility, they can only assist in doing so".⁵ Its evaluation overview says plainly that "no tool alone can determine if a site meets accessibility standards" and that "knowledgeable human evaluation is required to determine if a site is accessible".⁶

There is a number behind this. When the UK's Government Digital Service built a deliberately broken test page with 143 known barriers and ran ten automated tools against it, the best tool found about 41% of the barriers, and 42 of the 143, roughly 29%, were missed by every tool tested.⁷ So automated testing, at its best, finds something like a third to perhaps a half of the issues, and a solid third are invisible to it.

That is not a reason to skip automated tools. They are fast, they run on every build, and they catch the mechanical failures reliably: missing alt attributes, empty labels, low contrast values, missing page language. Reputable ones include axe, which runs in browser extensions and test suites, Google Lighthouse, which is built into Chrome, and WAVE from WebAIM. Run one of these early and often, and fix what it flags. Just never report "the scanner passed" as if it meant "the site is accessible". It does not.

The manual pass, and testing with real users

The two thirds the scanner misses are the parts that need a human judgement, and they are often the ones that matter most. A manual pass against WCAG 2.1 AA covers at least these:

Keyboard only. Unplug the mouse. Tab through every page and every flow: navigation, menus, forms, the checkout, any modal or pop up. Can you reach everything, operate everything, and see where you are the whole time? Can you always get back out? This single test surfaces most operable failures, and no scanner does it well.⁷
Screen reader. Work through the key journeys with a screen reader such as NVDA or JAWS on Windows, or VoiceOver on macOS and iOS. Listen to whether links, buttons, images and errors are announced sensibly, and whether the reading order makes sense.
Zoom and reflow. Zoom the browser to 200% and check nothing is lost (1.4.4), then narrow the window to around 320 CSS pixels and check the content reflows into one column without a second scrollbar appearing sideways (1.4.10).⁴
Contrast. Measure the real colours of text and of interface components with a contrast checker, rather than trusting the eye.

Better still, and this is where conformance becomes confidence, test with people who actually use assistive technology day to day. The W3C recommends involving people with disabilities throughout a project, not only at the end, because they find problems that pass every technical check yet still make a task hard.⁶ You do not need a lab. A couple of sessions with experienced screen reader users will teach you more than any report.

The honest summary of testing is this: automated for the mechanical, manual for the human, and real users for the truth. Any one of the three alone leaves gaps.

The failures I see most, and how they are fixed

Most of what fails an audit is a short list, repeated. Here is the list with the fix for each, and the success criterion it sits under.

Low colour contrast is the single most common failure, usually pale grey text on white or light text on a brand colour. WCAG 2.1 AA asks for a contrast ratio of at least 4.5:1 for normal text and at least 3:1 for large text, where large means from 18 point, or 14 point bold (1.4.3).⁴ Interface components and meaningful graphics need at least 3:1 against what is next to them (1.4.11).⁴ The fix is to measure and darken, and to set an accessible palette once so the problem does not come back with the next brand refresh.

Images without a text alternative come next. A decorative image should have an empty alt so a screen reader skips it; an informative one needs an alt that conveys its meaning; an image that is also a link must describe where the link goes (1.1.1).⁴ The fix is a rule in your content process: no image ships without a decision about its alt text.

Form fields without real labels are everywhere, usually because a placeholder is doing the job of a label and then vanishes as soon as the user types. Every field needs a programmatic label tied to it, so assistive technology announces it (3.3.2), and errors need to be named in text with a suggested fix (3.3.1 and 3.3.3).⁴ The fix is a proper <label> per field and error messages that say what to do.

Keyboard traps and custom controls that the keyboard cannot reach are the classic result of rebuilding native elements by hand. A menu, a date picker or a modal built from plain <div> elements often cannot be opened, operated or closed without a mouse (2.1.1 and 2.1.2).⁴ The fix is almost always to use the native HTML element, and where a custom component is unavoidable, to give it the keyboard behaviour and the name, role and value that the native one would have had (4.1.2).⁴

A missing or invisible focus indicator leaves keyboard users lost on the page. Browsers show a focus outline by default, and the usual cause of the failure is CSS that removes it for looks. The fix is to keep a clear, visible focus style rather than hiding it (2.4.7).⁴

None of these is exotic. They are ordinary engineering decisions, and the reason they recur is that they were never made deliberately in the first place.

Worked example: a Leeds shop brought to WCAG 2.1 AA

Kirkgate Kitchenware is an invented business, a Leeds company selling cookware online at kirkgatekitchen.example, with a catalogue, a checkout and a small account area. The owner has read that the law now names online shops and wants the site built and tested to WCAG 2.1 AA. Here is how the work ran. The figures below are illustrative of this example, not a claim about any real client.

I started with an automated scan on every template, using axe in the test suite and a WAVE pass by hand. It flagged 34 contrast failures, 12 images with no alt, and three form fields whose only label was a placeholder. Those went onto the list first, because they are real failures and the quickest to fix.

Then the keyboard pass, mouse unplugged. The main navigation worked, but the "quick view" product pop up trapped focus: once opened with the keyboard it could not be closed without a mouse, a 2.1.2 failure.⁴ The quantity stepper on the basket, built from styled <div> elements, could not be operated by keyboard at all, a 2.1.1 and 4.1.2 failure.⁴ Neither showed up in the scan.

The screen reader pass found that the checkout's error summary turned the invalid fields red but announced nothing, so a blind user filling the form heard the page reload and had no idea what had failed, a 3.3.1 failure.⁴ Zooming to 200% and narrowing to 320 pixels showed the product grid holding three columns and forcing a sideways scrollbar instead of reflowing, a 1.4.10 failure.⁴

The fixes were ordinary. I darkened the palette to clear 4.5:1 for text and 3:1 for the buttons and set those as tokens, which cleared all 34 contrast failures at once.⁴ I replaced the quick view and the quantity stepper with native elements that carry their own keyboard behaviour and roles. I added real <label> elements and an error summary that names each problem in text and moves focus to it. I let the grid reflow to a single column below the breakpoint. Finally I ran two sessions with regular screen reader users, who caught that the "add to basket" confirmation gave no spoken feedback, so I added a polite live region to announce it.

The result is a site built and tested to WCAG 2.1 AA, with the test record to show for it: the scan results, the manual checklist, the user session notes, and the list of fixed issues with the criterion each one met. If the owner later wants independent assurance, an accessibility auditor can verify conformance against that record. That is the honest shape of a conformance claim, and it is why I never say "guaranteed compliant".

What it is worth beyond the law

Accessibility is easy to treat as a tax, something you do because a regulator says so. That reading misses most of the value.

The obvious gain is reach. A site built to AA works for people with permanent disabilities, and also for the much larger group with a temporary or situational limit: a broken arm, bright sunlight on a phone, a noisy train where captions matter, an ageing eye that needs larger text. Every one of them is a customer you keep rather than lose at the first hurdle.

The second gain is that the same work improves the site for everyone. Proper heading structure, descriptive links, fast keyboard paths and clear error messages are plain good usability, and they help conversion, not only compliance. The overlap with search is real too, because the structure a screen reader relies on, headings, labels, text alternatives and clean markup, is largely the same structure a search engine reads.

The third gain is risk. The duty is legal, and I cover the who and the when in the accessibility law article. Building to the standard from the start is far less expensive than retrofitting under a complaint, and it is the kind of engineering discipline that sits alongside the other quality bars in my overview of quality tiers for business critical software.

How I build and test to this

I build SaaS platforms on Ruby on Rails and shops on Solidus, and I build them to WCAG 2.1 AA from the first commit rather than bolting it on at the end. In practice that means native HTML elements wherever possible, semantic structure with real headings and landmarks, labels tied to every form field, a colour palette chosen once to clear the AA contrast ratios, a visible focus style kept rather than removed, and errors that are named in text and can be reached.

The testing follows the mix above, not a single tool. Automated checks run in the test suite on every build, so a contrast or label regression fails the build the way a broken test would. I run the keyboard only and screen reader passes by hand on the key journeys, and the zoom and reflow checks at 200% and 320 pixels. Where it is warranted, I arrange sessions with people who use assistive technology, because that is the only test that tells you whether the thing is actually usable. And I keep the record, the scan output, the manual checklist and the fixed issues, because that record is what an independent audit builds on.

What I do not do is sell a badge or promise a guarantee. WCAG is a standard you meet and keep meeting as the site changes, and the only honest proof is the testing and the fixes, verifiable by an auditor if you want the assurance in writing.

What to do now

If you are starting a build, set WCAG 2.1 AA as the target from the outset and pick up the WCAG 2.2 additions where they are low cost, because retrofitting is the expensive path. If you have an existing site, run an automated scan today to find the mechanical failures, then book a manual pass, because the scan is at best a third of the picture.⁷ Either way, keep the test record, because a claim without evidence is just a hope.

And if you are not sure whether the law reaches you at all, or which parts of your product it touches, read the accessibility law article first, then come and talk it through.

W3C Web Accessibility Initiative, WCAG 2 Overview (publisher, and the publication dates of WCAG 2.0 on 11 December 2008, WCAG 2.1 on 5 June 2018 with later editions, and WCAG 2.2 on 5 October 2023), https://www.w3.org/WAI/standards-guidelines/wcag/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
W3C Web Accessibility Initiative, What's New in WCAG 2.1 (WCAG 2.1 adds 17 success criteria to WCAG 2.0), https://www.w3.org/WAI/standards-guidelines/wcag/new-in-21/ ↩ ↩²
W3C Web Accessibility Initiative, What's New in WCAG 2.2 (nine additional success criteria and the removal of 4.1.1 Parsing), https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/ ↩ ↩²
W3C, Web Content Accessibility Guidelines (WCAG) 2.1, W3C Recommendation, current edition 6 May 2025 (the four principles, conformance levels A, AA and AAA, and success criteria 1.1.1, 1.2.2, 1.2.5, 1.3.1, 1.4.1, 1.4.3, 1.4.4, 1.4.10, 1.4.11, 2.1.1, 2.1.2, 2.4.3, 2.4.7, 3.1.1, 3.3.1, 3.3.2, 3.3.3 and 4.1.2), https://www.w3.org/TR/WCAG21/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶ ↩²⁷
W3C Web Accessibility Initiative, Selecting Web Accessibility Evaluation Tools (tools cannot check all aspects automatically and cannot determine accessibility), https://www.w3.org/WAI/test-evaluate/tools/selecting/ ↩
W3C Web Accessibility Initiative, Evaluating Web Accessibility Overview (no tool alone can determine conformance, knowledgeable human evaluation is required, and involving people with disabilities), https://www.w3.org/WAI/test-evaluate/ ↩ ↩²
Government Digital Service, What we found when we tested tools on the world's least accessible webpage, Accessibility in government blog, 24 February 2017 (ten tools against 143 known barriers, best tool about 41%, 42 barriers missed by every tool), https://accessibility.blog.gov.uk/2017/02/24/what-we-found- ↩ ↩² ↩³