Web accessibility standards just got an update. WCAG 2.2 (Web Content Accessibility Guidelines) was released to help make websites more usable for people with cognitive and motor disabilities without leaving behind the users already served by WCAG 2.1.
Here are the 9 new success criteria added in WCAG 2.2, including their technical references and conformance levels.
Keyboard users must always be able to partially see which element has focus. If something like a sticky header or popup completely covers a button or link while it’s focused, it fails.
We see this a lot with widgets that stay in place as you scroll through a web page. At some point, it may overlap with a clickable element. The single A standards allow for some partial coverage, but it should still be clear where the user’s focus is.
This is a stricter form of 2.4.11 that states the entire focused element must be clearly visible. No overlapping at all.
When a user tabs through a page, the visible focus indicator (usually an outline) must have a contrast ratio of at least 3:1 with the background, and the thickness or area large enough to be noticeable. It’s easy enough to test for the contrast ratio with online tools like WebAIM’s color contrast checker. For thickness, the official guidelines state that a focus indicator must enclose at least the equivalent of a 2px solid border on all sides or cover an area equal to 4 CSS pixels.
If a task like sorting or moving an item requires dragging with a mouse or finger, users must be able to do it without dragging. Usually, these functions have secondary keyboard controls. Or those image uploaders that let you drag an image into a box to perform the upload. Those usually come with a fallback link that people can click on.
This is a less strict version of the 2.5.5 criterion from WCAG 2.1. Instead of interactive elements needing to be 44 pixels by 44 pixels, the AA version states interactive elements must be at least 24 pixels by 24 pixels or spaced out enough to prevent accidental taps or clicks. The spacing part refers to adding padding to an element. So, the object itself can be 20 pixels by 20 pixels, but having 2 pixels of padding on every side will make it compliant.
If help is provided via a contact number, support link, or chat widget, and it appears on multiple pages, it must be placed consistently across those pages.
Users should never be forced to re-enter the same information in multi-step processes unless it’s essential. If you ask the user to type in their email and then ask for it again in the same form, that’s not compliant.
Logging in shouldn’t depend on a user’s ability to remember or solve a puzzle unless there’s an alternative like an autofill code. This targets those CAPTCHA puzzles that ask you to select all the buses or motorcycles and is specifically for identity verification. This criterion applies to forms that ask you to log in, recover an account, or authenticate before accessing secure content. Normal contact forms do not fall under this standard.
This goes even further than 3.3.8 by saying users must be able to log in without any cognitive function test at all. This includes requiring users to copy a code from an email or remember anything unless an alternative like autofill or passkey is available.
Methods that are acceptable include:
WCAG 2.2 helps make digital spaces more inclusive and compliant. Whether you're trying to avoid legal risk or build a brand that works for everyone, these new standards are worth understanding and applying. If you need help testing your site against WCAG 2.2 standards, contact DiscoverTec today.
Published on: October 07, 2025 by Ryan Brooks