The Web Content Accessibility Guidelines have gone through three major versions since 2008. Each one builds on the last. If you have ever wondered which version your business needs to care about — and why — this page breaks it down without the developer jargon.
|
|
WCAG 2.0
|
WCAG 2.1
|
WCAG 2.2
|
|---|---|---|---|
|
Published
|
December 2008
|
June 2018
|
October 2023
|
|
The problem it solved
|
Set the original baseline for accessible web content
|
Caught up with mobile devices and touchscreens
|
Improved keyboard navigation, button sizing, and cognitive accessibility
|
|
New criteria added
|
Starting point — 61 total
|
17 new criteria added
|
9 new criteria added, 1 removed
|
|
Total criteria
|
61
|
78
|
86
|
|
Who it mainly helps
|
Screen reader users, people with visual impairments
|
Mobile users, low-vision users, people with cognitive disabilities
|
Keyboard users, people with motor disabilities, people with cognitive disabilities
|
|
Laws that reference it
|
AODA (Canada), Section 508 (US)
|
ADA interpretation (US DOJ 2024), EAA (EU, current)
|
Current best practice — where regulations are heading
|
|
What it means for your business
|
Minimum historical baseline
|
Legal standard in most active enforcement today
|
The version to build toward right now
|
|
Backward compatible?
|
Yes — it is the foundation
|
Yes — meets 2.0 automatically
|
Yes — meets 2.1 and 2.0 automatically
|
WCAG 2.0 was built in an era before smartphones. By 2018, the web had changed completely and the guidelines had not kept up. WCAG 2.1 added 17 new criteria to close those gaps. The big themes:
Mobile and touchscreen usability: can users pinch, rotate, and tap on your site? Does your layout reflow on a small screen without horizontal scrolling?
Low vision support: do your buttons and icons have enough contrast, not just your text? Can users override your font sizes without breaking the page?
Cognitive accessibility: can voice control users navigate using the labels they see on screen? Do status messages get read aloud by screen readers?
If your site was built after 2018 by a decent developer, you likely meet most of these already. If it was not, WCAG 2.1 is where the gaps usually show up.
WCAG 2.2 added 9 new criteria and removed one outdated one. The focus is on three things businesses actually recognize as real user problems: can people see where they are on your page, can they tap the right button, and can they log into your site without memorizing codes.
Here is each one in plain English, with the official reference for your developer or auditor:
Official name: 2.4.11 Focus Not Obscured (Minimum) — Level AA
Many websites have headers or cookie banners that stick to the top of the screen as you scroll. If a keyboard user tabs to a button that sits behind one of those banners, they cannot see it. This criterion requires that at least part of the focused element is always visible.
Official name: 2.5.7 Dragging Movements — Level AA
Sliders, sortable lists, and map controls often require a click-hold-drag action. For users with hand tremors or limited motor control, that is unreliable or impossible. This criterion requires a single-click or tap alternative for anything that uses dragging.
Official name: 2.5.8 Target Size (Minimum) — Level AA
Buttons, links, and form controls need to be at least 24 by 24 CSS pixels, or have enough space around them so that tapping one does not accidentally activate the one next to it. This matters most on mobile, and for users with hand tremors or limited fine motor control.
Official name: 3.2.6 Consistent Help — Level A
If your site has a chat button, a phone number, or a help link in the footer, it should appear in the same location on every page that shows it. Users with cognitive disabilities depend on predictable layouts to find support.
Official name: 3.3.7 Redundant Entry — Level A
If a user filled in their address at step one of a checkout, do not ask for it again at step three. Information already entered in a session should be auto-filled or available to select again. Retyping the same data in the same process is a failure under this criterion.
Official name: 3.3.8 Accessible Authentication (Minimum) — Level AA
If your login process requires solving a puzzle, recognizing distorted characters, or memorizing a code, you need to offer an alternative method. Allowing password manager autofill satisfies this. Standard image-recognition CAPTCHAs where users identify objects like traffic lights are still permitted under exceptions.
Official name: 2.4.12 Focus Not Obscured (Enhanced) — Level AAA
The stricter version of criterion 1 above: when a keyboard user focuses on an element, nothing should cover any part of it. No exceptions. This is an AAA criterion — optional for most businesses, but worth targeting for healthcare, government, or financial services.
Official name: 2.4.13 Focus Appearance — Level AAA
The visible outline that shows a keyboard user where they are on a page needs to meet specific size and contrast requirements. It must cover at least a 2-pixel perimeter of the focused element, and the focused state must have at least a 3:1 contrast ratio compared to the unfocused state. AAA — optional but good practice.
Official name: 3.3.9 Accessible Authentication (Enhanced) — Level AAA
The stricter version of criterion 6: no cognitive tests at any step of authentication, no exceptions at all. No object recognition, no user-uploaded image matching. AAA — typically relevant for healthcare and public-sector services.
One criterion was removed: 4.1.1 Parsing.
In plain English, this criterion originally required that your HTML had no coding errors, because older screen-reading software could not handle malformed markup. Modern browsers have since been updated to handle HTML errors automatically, so the criterion no longer protects anyone. It was quietly retired.
What this means for your business: minor HTML errors no longer count as a WCAG failure on their own. Clean, semantic code still matters — it is just covered by other criteria now.
|
Regulation
|
Where it applies
|
WCAG version referenced
|
|---|---|---|
|
AODA
|
Ontario, Canada
|
WCAG 2.0 AA — this is the legal reference and does not change
|
|
ADA (DOJ 2024 rule)
|
United States — state and local government
|
WCAG 2.1 AA
|
|
ADA (private business, courts)
|
United States
|
WCAG 2.2 AA increasingly cited
|
|
EAA / EN 301 549
|
European Union
|
WCAG 2.1 AA now, moving toward 2.2
|
|
Section 508
|
US federal government
|
WCAG 2.0 AA, updates pending
|
|
Best practice for any site
|
Everywhere
|
WCAG 2.2 AA
|
The short version: aim for WCAG 2.2 AA. It covers every lower version automatically, it is where regulators are heading, and it is the standard that courts and legal teams are starting to reference regardless of what the specific law says.
AccessPro is designed to support WCAG 2.2 AA by adding user-facing accessibility features to your site. It does not replace the source-code remediation required for full WCAG conformance. For source-code audit and remediation services, our partner team is available.
