WCAG 2.2 in plain English for small sites

WCAG stands for Web Content Accessibility Guidelines. It is the standard that almost every accessibility law, procurement checklist and audit report points to. Version 2.2 was published by the W3C on October 5, 2023. It keeps everything from 2.0 and 2.1, adds nine new success criteria, and retires one.

The official text is precise and dense, because it has to be. This is the version you can read in ten minutes, with the new criteria explained and a short list of what to fix first.

How WCAG is organized

The guidelines sit under four principles. Content has to be:

• Perceivable. People can see or hear it. Alt text, captions, contrast.
• Operable. People can use it. Keyboard access, enough time, no traps.
• Understandable. People can follow it. Clear labels, predictable navigation, helpful errors.
• Robust. It works with assistive technology. Proper names, roles and states on controls.

Under the principles are numbered success criteria, each with a level: A, AA or AAA. Level A is the floor. AA is what laws and contracts almost always mean when they say “WCAG compliant”. AAA is the strictest level, and the W3C itself doesn’t recommend requiring it for a whole site.

WCAG 2.2 is backwards compatible. If your site meets 2.2 at level AA, it also meets 2.1 and 2.0 at AA. So even if a regulation still names 2.1, there is no downside to working from 2.2.

The nine new success criteria

2.4.11 Focus Not Obscured (Minimum), level AA

When someone tabs to a link or a form field, that element must not be completely hidden behind something you put on the page. The usual culprits are sticky headers, cookie banners, chat bubbles and bottom bars. The keyboard focus moves to a button, but the button sits under the cookie banner, so the person has no idea where they are.

Fix: keep sticky bars small, make banners dismissible, and use scroll-padding on the page so focused elements scroll into clear view.

2.4.12 Focus Not Obscured (Enhanced), level AAA

Same idea, stricter: no part of the focused element may be covered. Nice to have, not required for AA.

2.4.13 Focus Appearance, level AAA

This one sets a minimum size and contrast for the focus indicator: roughly a 2 CSS pixel outline around the whole element, with a 3:1 contrast change between the focused and unfocused states. It is AAA, so it is optional, but a thick, high-contrast focus ring is cheap and helps everyone who uses a keyboard. A visible focus indicator of some kind is already required at AA by the older criterion 2.4.7 Focus Visible.

2.5.7 Dragging Movements, level AA

Anything a visitor can do by dragging must also be possible with a simple click or tap, unless dragging is essential to the task. Think sliders, sortable lists, kanban boards, map panning and “drag to upload” areas.

Fix: add buttons. A price slider gets number inputs. A sortable list gets “move up” and “move down”. A map gets arrow buttons or a search box. Dropping a file onto a zone is fine as long as there is also a “choose file” button.

2.5.8 Target Size (Minimum), level AA

Clickable things need to be at least 24 by 24 CSS pixels, or have enough space around them that a 24 pixel circle around each target does not overlap the next one. This is about people with tremors, people using a finger on a small screen, and anyone with a cheap mouse.

There are exceptions. Links inside a sentence do not count. Default browser controls do not count. If the same action is available somewhere else at a proper size, the small one is allowed.

Fix: pad your icon buttons, space out the social links in your footer, and check pagination controls, which are often too small.

3.2.6 Consistent Help, level A

If your site offers a way to get help, such as a phone number, a contact form, a chat widget or a help center link, and it appears on more than one page, it should be in the same relative place on each of those pages. Someone who found “Contact” in the footer on one page should find it in the footer on the next.

Fix: put help links in your shared header or footer and leave them there.

3.3.7 Redundant Entry, level A

Do not make people type the same information twice in the same process. If the shipping address was entered on step one, step three should offer it with a checkbox or pre-fill it, not present an empty form again. Exceptions exist for security, such as confirming a password, and for information that is no longer valid.

Fix: the “same as shipping” checkbox, and keeping values in the form when someone goes back a step.

3.3.8 Accessible Authentication (Minimum), level AA

Logging in must not depend on a cognitive function test unless there is a way around it. A cognitive function test means memorizing a password, solving a puzzle, transcribing characters, or doing arithmetic. The way around it can be a different method, such as a magic link, a passkey or single sign-on, or a mechanism that helps, such as letting a password manager fill the field and allowing paste.

At the minimum level, two kinds of test are still allowed: recognizing objects (pick all the pictures with a bicycle) and recognizing content the person provided themselves (pick the photo you uploaded).

Fix: never block paste in login fields, never fight password managers, and offer a second way in.

3.3.9 Accessible Authentication (Enhanced), level AAA

The same, without the object recognition and personal content exceptions. If you can avoid picture puzzles altogether, you meet this one too.

The one that was removed: 4.1.1 Parsing

Criterion 4.1.1 asked for well-formed markup: no duplicate IDs, properly nested elements, complete start and end tags. In 2.2 it is gone. Browsers and assistive technologies now cope with imperfect HTML, and the real problems it used to catch, such as a duplicate ID breaking a form label, are already failures under other criteria like 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value.

Sloppy HTML still causes problems. You just no longer get a separate failure for it.

What a small team should fix first

Nine new criteria sound like a lot. In practice, on a typical small site, they boil down to a short list of changes, most of them CSS.

1. Target size (2.5.8). Open your site on a phone and look at every icon button, pagination link and footer icon. Make them 24 pixels or give them room. Often it’s half an hour of CSS.
2. Focus not obscured (2.4.11). Tab through your home page and your checkout with a cookie banner open and a sticky header showing. If focus disappears under either, shrink the bar or make the banner go away on first interaction.
3. Consistent help (3.2.6). Check that your contact link lives in the same spot on every template. Usually it already does.
4. Redundant entry (3.3.7). Look at any multi-step form: checkout, sign-up, booking. Add pre-fill or “same as” options.
5. Accessible authentication (3.3.8). Remove any paste blocking on login forms. If you use a puzzle CAPTCHA, switch to one that is invisible or offer an email link as an alternative.
6. Dragging movements (2.5.7). Only relevant if you have drag interfaces. Most small sites do not.

Leave the three AAA criteria for later. A thick, high-contrast focus ring gets you most of the way to 2.4.13 anyway.

Do not forget the old criteria

The new criteria get the attention, but they are not where small sites fail most. The failures that fill audit reports year after year are older and simpler:

• Images without alt text (1.1.1). We wrote a whole guide on writing alt text that actually helps.
• Text and background colors that do not reach 4.5:1 contrast (1.4.3).
• Form fields with no label, or a placeholder doing the label’s job (1.3.1, 3.3.2).
• Links that just say “read more” or “click here” (2.4.4).
• Text that looks like a heading but isn’t marked up as one (1.3.1). Skipped heading levels and pages with no H1 aren’t WCAG failures on their own, but most checkers flag them and they make a page harder to scan.
• Menus and modals that cannot be opened or closed with a keyboard (2.1.1).
• Focus that vanishes because someone set outline: none (2.4.7).
• A missing lang attribute on the page (3.1.1).

If you only have a weekend, spend it on that list before the 2.2 additions.

How to check your own site

Automated scanners catch a large share of the issues above. They are very good at missing alt text, contrast, unlabeled fields, missing landmarks and broken ARIA. They cannot tell you whether your alt text is any good, whether your focus order makes sense, or whether a custom dropdown is usable with a keyboard. For those, you test by hand: unplug the mouse, tab through a key flow, and listen to one page with a screen reader.

Accessora’s audits run an axe-core scan on each page you add and list what it finds, with the WCAG criterion and level, how serious it is and the elements affected, so you can hand the list to a developer or work through it yourself. The checks apply the same way whether the site runs on WordPress, Webflow or hand-written HTML.

One last thing. A widget that lets visitors change font size and contrast is useful, and we make one, but it doesn’t make your code meet any of the criteria above. WCAG is about the pages you ship, so that’s where the fixes go. There’s more on why in Widgets, overlays and real fixes: an honest guide.