What Is the Latest Version of WCAG?

The latest version of WCAG is WCAG 2.2, which the W3C published as a Recommendation on 5 October 2023 and updated on 12 December 2024. WCAG 3 is still a working draft rather than a standard, so WCAG 2.2 AA is the level UK organisations should be testing against today. For public bodies this is also the level GOV.UK now refers to, which is why it sits at the centre of our accessible web design for the public sector and the audits we carry out for councils, NHS Trusts and education providers.

Many accessibility statements, procurement documents and older articles still refer to WCAG 2.1 and some describe WCAG 3 as if it had already replaced the current standard. Neither reflects where things stand in October 2026. This guide sets out which version is current, what changed in 2.2, how it applies under UK law and what is known about WCAG 3 so far.

Which WCAG Version Applies Today

WCAG 2.2 is the current version and the one the W3C asks organisations to use. According to the W3C’s WCAG 2 overview, WCAG 2.0 was published in December 2008, WCAG 2.1 in June 2018 and WCAG 2.2 in October 2023, with an update to 2.2 in December 2024. The same page confirms that WCAG 2.2 is now an approved international standard, ISO/IEC 40500:2025, which matches the October 2023 text.

The short answer to the version question breaks down as follows. Each point is drawn from the W3C and GOV.UK sources covered in the sections below.

• WCAG 2.2 is the latest published standard and the one to test against.
• WCAG 2.1 remains valid, but it lacks the nine success criteria added in 2.2.
• WCAG 2.0 is the original WCAG 2 standard and is now well out of date for new work.
• WCAG 3 is an incomplete working draft and cannot be used to claim conformance.
• UK public sector bodies are expected to meet WCAG 2.2 at level AA.

The versions build on one another, so meeting the newest one covers the older ones too. The WCAG 2.2 Recommendation states that content conforming to WCAG 2.2 also conforms to WCAG 2.0 and WCAG 2.1, which means a policy written around an earlier version can be satisfied by working to 2.2.

How WCAG Is Structured

WCAG is organised into principles, guidelines and testable success criteria, with each criterion assigned a conformance level. The W3C overview explains that WCAG 2.2 contains 13 guidelines grouped under four principles, often shortened to POUR and that every success criterion sits at level A, AA or AAA.

The terms below come up in audits, tender documents and accessibility statements. It helps to be clear about what each one means before looking at the changes in 2.2.

Success criterion

A testable statement that content either passes or fails. Conformance to WCAG is judged on success criteria, not on the guidelines above them.

Conformance level

Each criterion is rated A, AA or AAA. Meeting level AA means meeting every A and AA criterion that applies to the content.

W3C Recommendation

The final, stable status of a W3C standard. WCAG 2.0, 2.1 and 2.2 all hold this status.

Working Draft

A document still being developed and open for comment. WCAG 3 is at this stage and its content is expected to change.

Level AA is the target for most organisations because it covers the barriers that affect the widest range of users while staying practical to achieve. Our article on the difference between A, AA and AAA in WCAG explains why AAA is usually applied selectively rather than across a whole website.

What Changed in WCAG 2.2

WCAG 2.2 added nine new success criteria and removed one. The W3C’s summary of what is new in WCAG 2.2 lists the additions, which focus on people with cognitive and learning disabilities, people with low vision and people with limited dexterity, including many who use mobile devices.

Six of the nine new criteria sit at level A or AA, so they form part of the standard most organisations are working to. The remaining three are AAA. The table summarises each one using the W3C’s own descriptions.

Target Size (Minimum) is the criterion teams ask about most. The WCAG 2.2 Recommendation sets the size of the target for pointer inputs at least 24 by 24 CSS pixels, with exceptions for spacing, inline links in text, equivalent controls elsewhere on the page and cases where a particular presentation is legally required or otherwise necessary.

The one removal is 4.1.1 Parsing, which the W3C now treats as obsolete. Browsers handle parsing errors far better than they did, assistive technologies now rely on the browser rather than parsing markup themselves and the issues Parsing used to catch now fail other criteria instead. The WCAG 2 FAQ covers how to treat Parsing if you still report against WCAG 2.0 or 2.1. For a closer look at each addition and how it plays out in design and development, see our guide to the WCAG 2.2 success criteria and what they mean.

Is WCAG 2.2 a Legal Requirement in the UK

For most public sector bodies, WCAG 2.2 AA is the standard their websites and mobile apps are expected to meet. GOV.UK guidance on accessibility requirements for public sector websites and apps says a website or app will meet the legal requirements if it meets WCAG 2.2 AA and publishes an accessibility statement explaining how accessible it is.

Those requirements come from the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. The Government Digital Service monitors compliance and its page on how public sector websites and apps are monitored names level AA of WCAG 2.2 as the technical standard it checks against.

Earlier versions of this article said public bodies needed to meet WCAG 2.1 AA and plenty of statements and contracts still say the same. GOV.UK updated its guidance to reference WCAG 2.2, so any accessibility statement or specification that still names 2.1 is worth reviewing.

Private sector organisations are not covered by the 2018 regulations, but they still have duties under the Equality Act 2010. Section 20 of the Act sets out the duty to make reasonable adjustments so disabled people are not placed at a substantial disadvantage. The Act does not name WCAG, yet WCAG 2.2 AA is the benchmark most organisations use to show their websites meet that duty.

Organisations selling into EU markets have a further consideration. The W3C overview notes that most organisations addressing the European Accessibility Act use WCAG alongside the EN 301 549 standard and that the 2026 version of EN 301 549 uses WCAG 2.2. Our guide to the European Accessibility Act explains who it applies to.

Moving From WCAG 2.1 to WCAG 2.2

A website that already meets WCAG 2.1 AA does not need rebuilding to meet WCAG 2.2 AA. The W3C confirms that the 2.0 and 2.1 success criteria are essentially unchanged in 2.2 apart from the removal of Parsing, so the work is about checking six new criteria at A and AA and fixing what falls short.

In practice, the effort depends on how the website was built. Sticky headers and cookie banners often hide focused elements, drag-only sliders and sortable lists need a single-pointer alternative and login screens sometimes rely on memory tests or block password managers. Across public sector and B2B projects, these patterns tend to sit in shared templates and components, which means one fix can resolve the issue across hundreds of pages.

That sequence mirrors how our website accessibility audits and remediation work. Each audit combines a manual review against WCAG 2.2 Level AA across critical user paths with an automated scan using axe-core and WAVE and produces a severity-ranked issue register, a prioritised roadmap and an accessibility statement template for organisations covered by the 2018 regulations. We also design and develop all WordPress websites to WCAG 2.2 AA as a minimum, so new builds start from the current standard rather than catching up later.

Testing a Website Against WCAG 2.2

Testing against WCAG 2.2 needs both automated tools and manual checks, because many of the new criteria depend on context that software cannot judge. Automated tools such as WebAIM’s WAVE evaluation tool and axe are quick at finding missing alternative text, contrast failures and markup problems across many pages.

Manual testing covers what those tools miss. Tabbing through each page shows whether focused elements are hidden behind fixed headers and whether focus moves in a logical order, while testing with screen readers such as NVDA on Windows and VoiceOver on Apple devices shows how content is announced. Checking that help links appear in a consistent place, that multi-step forms do not ask for the same details twice and that sign-in does not rely on a puzzle are all manual judgements. Our comparison of accessibility testing tools looks at where each tool fits.

Content changes can reintroduce issues after a website passes an audit, so testing is most effective as a regular task rather than a one-off project. Training editors to write alternative text, structure headings correctly and check new components before publishing keeps a compliant website compliant.

What We Know About WCAG 3

WCAG 3 has not been released and is not yet a standard. The W3C’s WCAG 3 introduction describes it as an incomplete draft that will change, intended to develop into a W3C Standard in a few years and the most recent WCAG 3.0 Working Draft is dated 10 September 2026.

The name itself signals a wider scope. WCAG 3 stands for W3C Accessibility Guidelines rather than Web Content Accessibility Guidelines and the W3C says it applies to web content, apps, tools, publishing and emerging technologies. It is designed to keep core requirements similar to WCAG 2, with revisions and additions and to introduce a conformance model that allows more specific reporting of progress.

That conformance model is still under discussion. The September 2026 updates substantially revised the conformance approach and an editor’s note in the draft records that the working group is exploring tiers, alongside an alternative proposal that would use scoring and then award Bronze, Silver and Gold after conformance. Articles that describe a settled Bronze, Silver and Gold rating system are therefore ahead of the evidence.

The W3C’s own advice is that meeting the WCAG 2.2 success criteria now is how organisations should prepare for WCAG 3. Accessibility work done to 2.2 AA today serves users immediately, satisfies current UK public sector guidance and gives any future move to WCAG 3 a sound starting point, which is a stronger position than waiting for a standard whose requirements have not yet been agreed.