WCAG
Date: 2026-08-17
The international standard for web accessibility, structured as testable success criteria at three conformance levels. It’s the reference every accessibility requirement points at, including UK law — and conformance is a floor, not a definition of usable.
WCAG — the Web Content Accessibility Guidelines — is a W3C standard defining testable criteria for accessible web content.
The structure
4 PRINCIPLES POUR
Perceivable can they sense it?
Operable can they use it?
Understandable can they comprehend it?
Robust does it work with
assistive technology?
↓
GUIDELINES broad goals
↓
SUCCESS CRITERIA testable statements
↓
LEVELS A · AA · AAA
Success criteria are the operative layer — each is a pass/fail statement you can check, which is what makes the standard usable as a requirement rather than an aspiration.
The levels
A minimum. Failing these blocks
people outright
AA the standard target. What law and
procurement almost always
reference
AAA enhanced. Not expected across a
whole site — some criteria are
impossible for some content
AA is the working target. The standard itself notes that AAA conformance across all content is not achievable for every site.
Versions
2.0 2008
2.1 2018 — added mobile, low vision,
cognitive criteria
2.2 2023 — added focus appearance,
dragging alternatives,
authentication criteria
3.0 in draft, a different model
entirely
[CHECK: which WCAG version and level your obligations reference, and the current status of WCAG 3.0, before treating any specific criterion as required. Requirements cite versions explicitly and they differ.]
Newer versions are additive — meeting 2.2 AA means meeting 2.1 AA and 2.0 AA.
The criteria that come up most
Not a substitute for the standard, but the ones that account for most real failures:
1.1.1 non-text content has a text
alternative
1.3.1 structure conveyed in the markup
— Semantic HTML
1.4.3 contrast 4.5:1 for text
— Colour Contrast
1.4.11 contrast 3:1 for UI components
2.1.1 everything reachable by keyboard
— Keyboard Navigation
2.4.7 focus is visible
— Focus Management
3.3.1 errors identified in text
— Accessible Forms
3.3.2 labels or instructions provided
4.1.2 name, role and value exposed
— The Accessibility Tree
See: Semantic HTML · Colour Contrast · Keyboard Navigation · Focus Management · Accessible Forms · The Accessibility Tree
Most failures are in a handful of criteria, and most of those are solved by using the right HTML element.
What automated testing catches
The number worth knowing, because it sets expectations:
AUTOMATED TOOLS
catch roughly a third of issues
→ missing alt, contrast, missing
labels, invalid ARIA
CANNOT CATCH
is the alt text MEANINGFUL?
is the focus order LOGICAL?
does the page make sense read aloud?
is the error message HELPFUL?
can a task actually be COMPLETED?
[CHECK: current published figures on automated detection coverage before citing a specific proportion.]
A clean automated scan is a starting point, not conformance. The criteria requiring judgement are the ones that block people.
Testing properly
1 AUTOMATED SCAN the cheap third
2 KEYBOARD ONLY unplug the mouse
and complete a
purchase
3 SCREEN READER one real flow
— Screen Readers
4 ZOOM to 400% does it reflow?
5 REDUCED MOTION on
6 WITH DISABLED USERS the only test that
tells you whether
it works
See: Screen Readers
Step 2 finds more real problems per minute than anything else and requires no tools.
Conformance versus usability
A site can meet AA and still be difficult to use. The criteria are necessary and not sufficient — alt text that technically exists but says “image1.jpg” passes an automated check and helps nobody.
Treat WCAG as the floor, and the actual question as whether a person using assistive technology can complete the task — Inclusive Design, Accessibility Law in the UK.