WCAG 2.2 for product teams: the changes that matter in practice

What WCAG 2.2 added

WCAG stands for Web Content Accessibility Guidelines. It is the main technical standard for accessible web content, published by the W3C. WCAG 2.2 became a W3C Recommendation in October 2023. You can read the full text at w3.org/TR/WCAG22, and the W3C also keeps a short page on what is new in 2.2.

It adds nine new success criteria. Six of them are at level A or AA, the levels most teams aim for. Three are at AAA, which is rarely required in full but is a useful guide. WCAG 2.2 also removes one old criterion, 4.1.1 Parsing, which no longer applies to modern browsers.

The new version builds on 2.1. Content that meets WCAG 2.2 also meets 2.1 and 2.0, so you do not have to choose between them. Many laws and contracts still name a particular version, often 2.1 AA, so check which one applies to you.

A note first: this post explains the standard in plain words. It is not legal advice. If you need to know whether a law applies to your product, ask a lawyer who knows accessibility law in your market.

Here are the changes that come up most in product work.

Focus visibility

Keyboard users move through a page with the Tab key. The focus indicator, usually an outline, shows where they are. If you cannot see it, you are lost.

WCAG already required a visible focus indicator (2.4.7 Focus Visible, level AA). WCAG 2.2 adds two criteria that go further.

2.4.11 Focus Not Obscured (Minimum), AA. When something gets keyboard focus, it must not be completely hidden by other content you added, such as a sticky header, a cookie banner or a chat widget. This is a common bug: you tab down a long page, and the focused link slides under the fixed header. The fix is often simple in CSS, with scroll-padding-top or scroll-margin that leaves room for the header.

2.4.13 Focus Appearance, AAA. The focus indicator should be reasonably large and have enough contrast. The criterion asks for an area at least as big as a 2 CSS pixel outline around the element, and a contrast of at least 3:1 between the focused and unfocused states. It is AAA, so not required by most rules, but it is a sound target for your design system. A thin, pale grey outline on a white page fails this and is hard to see.

In design, treat focus as a real state of every interactive component, drawn next to hover and pressed. Do not leave it for the developer to guess, or to remove with outline: none.

Target size

2.5.8 Target Size (Minimum), AA. Clickable and tappable targets should be at least 24 by 24 CSS pixels. This helps people with tremors, limited dexterity, or just a thumb on a small screen.

There are exceptions, and they matter:

• Spacing. A smaller target is fine if there is enough space around it, so that a 24-pixel circle centered on it does not touch another target.
• Inline links. Links inside a sentence or paragraph are exempt.
• Equivalent. If another control on the page does the same thing at a larger size, the small one can stay.
• Browser-controlled. Default controls that you have not restyled are exempt.
• Essential. When the size is needed for the information to work.

Where we see this fail in SaaS products: icon buttons in table rows, close buttons on toasts, small checkboxes, stacked action icons, pagination controls and dense toolbars. In dense B2B screens, the answer is not to make everything huge. It is to use spacing and to give the clickable area more room than the visible icon. A 16-pixel icon inside a 24-pixel button passes.

The older WCAG 2.1 criterion 2.5.5 Target Size asks for 44 by 44 pixels at AAA. That is a good size for the main touch targets on a phone.

Alternatives to dragging

2.5.7 Dragging Movements, AA. If a feature works by dragging, there must also be a way to do it with a single pointer, like a click or a tap, unless dragging is essential.

Dragging is hard for people who use a keyboard, a switch, voice control, or have limited hand control. In SaaS products it appears in:

• Kanban boards, where cards move between columns.
• Reordering lists, such as pages, fields or dashboard widgets.
• Sliders and range selectors.
• Upload areas that say "drag files here".
• Resizing panels and columns.

The fix is to add another way. A "Move to" menu on a card. Up and down buttons in a list. An input box beside a slider. A visible "Choose files" button next to the drop zone. Many products already have these for convenience, so check before you build more.

Accessible sign-in

3.3.8 Accessible Authentication (Minimum), AA. A sign-in step should not require a cognitive function test, such as remembering a password, solving a puzzle or copying characters, unless there is an alternative or help.

What this means in practice:

• Let people paste into password and code fields. Do not block paste.
• Support password managers, with proper field types and autocomplete attributes.
• Offer another way in, such as an email sign-in link, a passkey or a sign-in with another account.
• Be careful with CAPTCHAs that need puzzle-solving or transcribing distorted text. Give an alternative.

Also in this area are two small criteria that help in forms and flows:

• 3.3.7 Redundant Entry, A. Do not make users type the same information again in the same process. Prefill it, or offer a "same as billing address" option.
• 3.2.6 Consistent Help, A. If you offer help, such as a contact link, a chat or a help page, put it in the same relative place on each page.

That is nine in all: three on focus (2.4.11, 2.4.12 and 2.4.13), one each on target size, dragging, redundant entry and consistent help, and two on accessible authentication (3.3.8, plus an enhanced AAA version, 3.3.9).

How to check in design

Many of these checks can happen before any code exists.

• Draw a focus state for every interactive component, and check its contrast against the background.
• Check target sizes on icon buttons, checkboxes and row actions. Draw a 24-pixel square or circle over them in the design file.
• Look for fixed elements that could cover the focused item: headers, footers, banners and chat bubbles.
• List every drag interaction, and write down the alternative next to it.
• Walk through sign-up and sign-in, asking if any step needs memory or a puzzle.
• Look for repeated questions in multi-step flows.
• Check where help sits on different pages.

Then check the built product with a keyboard. Tab through the main flows, and watch for hidden focus, traps and missing indicators. Automated tools help, but they catch only part of the problems, and several of the new criteria need a person to check them.

Where to start in an existing product

If your product is live and you are unsure how it stands, start small.

1. Fix focus first. Make the focus style visible and consistent in your design system. It improves every screen at once.
2. Fix the sticky header problem with scroll padding.
3. Check target size on your most-used screens, especially tables and toolbars.
4. Review sign-in and sign-up. Allow paste and password managers.
5. Add alternatives to the main drag interactions.
6. Write down what you checked and what you changed. Records help if a customer or an auditor asks.

These are design and front-end changes that fit into a normal sprint. If you need a formal accessibility audit or a legal opinion, ask a specialist.

In a UX audit, we flag problems we see, such as small tap targets and missing focus styles, but it is not a full accessibility audit or a legal check. You can see what we build for ourselves in the Lab, and read about our focus on the SaaS design agency page. If you would like a quick look at one flow, send it to us for a free design review.