What is WCAG 2.2, and what changed from 2.1?
WCAG 2.2 is the W3C’s Web Content Accessibility Guidelines, version 2.2. It keeps the 2.1 criteria, adds nine new success criteria, and removes one, 4.1.1 Parsing. Content that met 2.1 needs only the new criteria checked to meet 2.2.
Of the nine additions, two sit at level A, four at level AA, and three at level AAA. The W3C’s summary of what is new lists them:
- Level A: 3.2.6 Consistent Help and 3.3.7 Redundant Entry.
- Level AA: 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), and 3.3.8 Accessible Authentication (Minimum).
- Level AAA: 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, and 3.3.9 Accessible Authentication (Enhanced).
The specification marks 4.1.1 Parsing as obsolete and removed. Modern browsers and assistive technology handle malformed markup in consistent ways, so the criterion no longer predicts real problems. Valid HTML is still good practice. It is no longer a conformance test.
Which conformance level should you aim for?
Aim for level AA. It is the level named in many accessibility laws and policies, including the ADA rule below, and it is achievable for a product without changing its design language. Level A is the floor, and level AAA is a goal for parts of a site, not a target for all of it.
In plain terms, level A covers barriers that block people outright, such as images with no text alternative or controls a keyboard cannot reach. Level AA adds the criteria that make a product usable in everyday conditions, such as contrast, resizing text, and visible focus. Level AAA asks for more than many products can deliver, and the W3C itself says it is not recommended as a general policy for entire sites.
Legal references vary by country and change over time, so check the current text. In the United States, the Department of Justice’s web rule under ADA Title II requires state and local government web content to meet WCAG 2.1 level AA, with compliance dates that the department publishes on that page. Teams building to 2.2 AA also meet that level, because the W3C states that content conforming to WCAG 2.2 also conforms to WCAG 2.1 (and 2.0).
What do the six new A and AA criteria require?
Six criteria are new at level A or AA, and each targets a specific failure that real products show. The headings below give the number, and the short answers state what the specification requires.
2.4.11 Focus Not Obscured (Minimum)
When a control receives keyboard focus, it must not be entirely hidden by content the author created. The usual culprits are sticky headers, cookie banners, and chat widgets that sit on top of the focused element as someone tabs down the page. A fix is usually CSS, such as scroll padding that leaves room below a fixed header. This is level AA.
2.5.7 Dragging Movements
Anything that works by dragging must also work with a single pointer, without dragging. A reorderable list needs move up and move down buttons. A slider needs a way to enter or step a value. The exceptions are dragging that is essential, and behavior the browser controls. This is level AA.
2.5.8 Target Size (Minimum)
Pointer targets must be at least 24 by 24 CSS pixels, with five exceptions: enough spacing around smaller targets, an equivalent control elsewhere on the page, inline links within a sentence, targets the browser sizes, and cases where the size is essential. Dense icon toolbars and table row actions fail most often. The W3C has a detailed page on Understanding Target Size (Minimum). This is level AA.
3.2.6 Consistent Help
If a page offers a help mechanism, such as a contact link, a chat, or a help page, and the mechanism repeats across a set of pages, it must appear in the same place relative to other content on each page. A support link that moves between templates fails. This is level A.
3.3.7 Redundant Entry
Information a person has already entered in the same process must be filled in for them or offered for selection when it is needed again. A shipping address that reappears as a billing address is the classic case. The exceptions are when re-entry is essential, required for security, or the earlier information is no longer valid. This is level A.
3.3.8 Accessible Authentication (Minimum)
A sign-in step must not depend on a cognitive function test, such as remembering a password or solving a puzzle, unless it offers an alternative, a helping mechanism, an object recognition test, or a test based on content the person supplied. In practice, let password managers work: allow paste, and use correct autocomplete attributes. This is level AA.
Where do real products fail first?
Products fail first on the older basics: color contrast, form labels, keyboard order, and focus visibility. The new criteria add a second group of failures that appear in sticky interface elements, dense controls, and multi-step forms.
This is the short list I start from. Is there text on a background that falls under the contrast ratios? Does every input have a label that a screen reader announces? Can a keyboard user reach everything, in an order that follows the layout? Does the focused element stay visible? Then the 2.2 additions: what covers the focus ring, what depends on a drag, which icons are smaller than 24 pixels, and whether sign-in allows a password manager.
Checkout, sign-up, and account settings concentrate these patterns. They have forms, sticky summaries, and repeated information in one flow.
How do you test for it?
Combine automated checks with hand testing, because tools catch only part of the list. A scanner can flag missing labels and low contrast. It cannot judge whether focus order makes sense or whether a task can be completed without a mouse.
A practical test pass has five parts:
- Automated scan. Run a checker on key templates to clear the easy failures.
- Keyboard pass. Complete the main tasks using only Tab, Shift+Tab, Enter, Space, and the arrow keys. Watch for hidden focus and traps.
- Screen reader pass. Complete the same tasks with one screen reader. Listen for missing names and confusing order.
- Zoom and reflow. Set the browser to 200 percent and check a narrow viewport. Content should stay usable without two-direction scrolling.
- Hand tests for the new criteria. Measure target sizes, look for anything that covers focus, list drag interactions, check where help links sit, and try the sign-in flow with a password manager.
Record each failure with the criterion number, the page, and the steps to reproduce it. The studio’s accessibility audits follow this structure, and the studio builds every website to WCAG 2.2 level AA.
What do you fix first?
Fix first what blocks someone from finishing a task, and rank the rest by how many people it affects and how much effort it takes. A missing label on the payment field outranks a small contrast shortfall on a footer link.
A simple ranking works. Give each finding a severity (does it block a task, slow it, or only annoy), a reach (how many pages and users it touches), and an effort estimate. Fix blockers on key flows first, then the cheap fixes with wide reach, then the rest. A short audit or sprint, described under ways to engage, is one way to run that ranking. Re-test after each round, since a fix in one component can break another.
Can an overlay or a plugin make a site compliant?
No. Conformance is judged on the page itself: its markup, its behavior, and its content. A script that sits on top can adjust some presentation, but it cannot repair missing labels, a broken focus order, or unclear content.
Overlays cannot repair a page’s markup, behavior, or content, and the WCAG conformance requirements apply to the page itself, as delivered. Real conformance comes from the design and the code. Use a plugin if it helps people adjust text size or contrast, and keep the underlying page accessible without it. Be wary of any product that promises compliance in a single step.
If you want an accessibility review of a product, or a build tested to this standard, email the studio. For the search side of the same standard of care, see what AEO is.