How do you make your website accessible? The WCAG 2.2 checklist for 2026

What standard are you aiming for?

WCAG 2.2 at Level AA — and being precise about that target saves a lot of wasted effort. WCAG 2.2 became the definitive web accessibility standard on 5 October 2023, and as of 2026 it is the baseline that accessibility laws around the world actually reference: the European Accessibility Act and its technical standard EN 301 549, US Department of Justice guidance for the ADA, and updated Section 508 all point to WCAG 2.2 Level AA (Web Accessibility Checker, 2026). If you are still auditing against the older WCAG 2.1, you are working from an outdated checklist.

The structure is worth knowing because it organizes everything that follows. WCAG 2.2 contains 87 success criteria grouped under the four POUR principles, at three conformance levels — A, AA and AAA (Web Accessibility Checker, 2026). The vast majority of organizations should target Level AA, which is the globally accepted and legally relevant tier; Level AAA is not required by law and not applicable to every kind of content (Level Access, 2026). And there is no rush to wait for what comes next: WCAG 3.0 is still in early draft and is not expected to become a standard for years, so WCAG 2.2 will remain the practical target through at least 2028 to 2030 (Web Accessibility Checker, 2026).

Perceivable: can everyone receive the content?

The first principle asks whether information is available to every sense, not only to sight. Give every meaningful image appropriate alternative text, and mark decorative images as decorative with an empty alt="" so a screen reader skips them rather than reading a filename (WebAIM, 2026). Provide captions for video and a descriptive transcript for audio, so the content is available to people who cannot hear it (WebAIM, 2026).

Then handle the visual layer. Text needs sufficient colour contrast against its background — a ratio of at least 4.5:1 for normal text at Level AA — and you must never use colour alone to convey meaning, since a colour-blind user will miss it (Webability, 2026). Text should resize and reflow without breaking the layout, so someone who zooms to 200% can still read and use the page. None of these are exotic; they are the baseline that makes a page perceivable to the widest audience.

Operable: can everyone use it without a mouse?

The second principle is about interaction, and the single most revealing test is the keyboard. Every function must be operable with a keyboard alone, with no keyboard traps where focus gets stuck, because many people navigate entirely by keyboard or by assistive technology that emulates one (WebAIM, 2026). Pair that with a visible focus indicator so a keyboard user can always see where they are, a logical focus order that follows the visual flow, and a “skip to content” link so they are not forced through the whole menu on every page (WebAIM, 2026).

The rest of operability is about clarity and safety. Link text should make sense on its own — “read the accessibility guide,” not “click here” — and every page needs a descriptive, informative title (WebAIM, 2026). Give users enough time to complete tasks rather than timing them out abruptly, and avoid content that flashes more than three times a second, which can trigger seizures. Operability is where a beautiful site most often fails quietly, because everything works with a mouse and no one checked the keyboard.

Understandable: is it predictable and clear?

The third principle covers comprehension and predictability. Set the page language in the markup so a screen reader uses the right pronunciation, keep navigation consistent from page to page, and make the interface behave predictably — components that look the same should act the same (WebAIM, 2026). Predictability is quietly important for people with cognitive disabilities, who are disproportionately affected when a layout shifts or a control behaves unexpectedly.

Forms are where this principle does the most work. Every input needs a clear, programmatically associated label and any instructions it requires; when a user makes an error, identify it clearly and suggest how to fix it rather than just rejecting the submission (WebAIM, 2026). For anything consequential — legal, financial or data submissions — make the action reversible, verified or confirmed, so a mistake is recoverable. Good form design is most of understandable accessibility in practice.

Robust: will assistive technology parse it?

The fourth principle is about whether machines can interpret your page, which is where accessibility and AI-readability overlap. The foundation is semantic HTML: use real elements for their real purpose — a <button> for a button, a heading for a heading, a list for a list — so assistive technology understands the structure without guessing (WebAIM, 2026). This is the same semantic discipline that makes a page readable to search engines and AI assistants, which is why this principle shows up in both our accessibility and our AI-readability work.

Where native HTML is not enough, use ARIA correctly to provide a name, role and value for custom components — and only where HTML cannot do the job, because incorrect ARIA is worse than none (WebAIM, 2026). One specific, often-missed requirement: when an important status message appears without moving focus — “message sent,” “item added to cart” — it must be announced to screen reader users through an ARIA live region, so they get the same feedback everyone else does (GetWCAG, 2026).

What’s new in WCAG 2.2 — the criteria to add?

WCAG 2.2 added nine success criteria and removed one obsolete one, targeting three groups the previous version underserved: people with low vision, with cognitive and learning disabilities, and mobile users with motor impairments (Web Accessibility Checker, 2026). The ones that matter most at Level AA are concrete and design-led. Focus Not Obscured requires that a focused element is not hidden behind a sticky header or cookie banner. Dragging Movements requires that anything you can drag — a slider, a drag-and-drop list — also works with a single pointer action, like a click on a start and end point (Accessible.org, 2026).

The other additions are just as practical. Target Size (Minimum) requires interactive targets to be at least 24 by 24 CSS pixels, so people with motor impairments do not hit the wrong control (GetWCAG, 2026). Accessible Authentication means a login cannot depend on a cognitive function test like remembering a password or solving a puzzle, unless there is an alternative — an email link or a password manager that can paste satisfies it (Accessible.org, 2026). Two Level A additions round it out: Consistent Help, keeping support in the same place across pages, and Redundant Entry, not making users re-enter information they already gave in the same process. Most of these are best addressed during design rather than patched in testing (Level Access, 2026).

How do you test it — and why aren’t automated scans enough?

You test in two layers, and the order matters. Start with automated tools like axe DevTools, WAVE and Lighthouse, which quickly surface machine-detectable issues such as missing alt attributes and low contrast (Accessibility Innovations, 2026). But they are a starting point, not a verdict: automated scanners catch only a portion of WCAG criteria — by most estimates around a third — because the rest require human judgment (Webability, 2026).

The second layer is where accessibility is actually confirmed. Navigate the site with only a keyboard, then with a screen reader, then on a real mobile device with touch, to test the things a machine cannot judge — logical focus order, whether alt text is meaningful, whether a custom widget actually works (Accessibility Innovations, 2026). The most common mistakes are relying only on automated scans, checking the homepage but not templates, forms and dynamic components, and forgetting legacy content like old PDFs (Webability, 2026). One thing manual testing is not is an overlay widget — for why the one-click accessibility tool fails and creates legal risk, see our guide on whether accessibility overlays are a legal trap.

How do you prove it? Accessibility statements and VPATs

You document conformance, because there is nothing to certify. There is no official WCAG certification body — the W3C does not issue compliance certificates — so proof takes the form of documentation you produce (Web Accessibility Checker, 2026). The baseline is a self-declared accessibility statement that records your conformance level, any known issues, and a way for users to report barriers — which is also a legal requirement in some jurisdictions.

For more formal contexts, two documents carry weight. A VPAT (Voluntary Product Accessibility Template) lists your conformance status criterion by criterion, and is commonly required in B2B and government procurement; a signed report from a professional auditor is the strongest evidence, and many procurement processes accept it (Web Accessibility Checker, 2026). It is worth being clear that WCAG conformance is not the same as legal compliance — but in the current legal landscape it is the recommended best practice for reducing the risk of an accessibility lawsuit (Level Access, 2026).

Build it in, don’t bolt it on

The thread running through every principle is that accessibility is cheapest and best when it is built in, not added later. Most of the new WCAG 2.2 criteria are best addressed during design rather than retrofitted in testing, and accessibility done well is an ongoing practice — checked on every template and release — rather than a one-time exercise (Level Access, 2026). A site that treats it as a launch checklist will drift out of conformance with the next feature.

If the full list feels long, start where the impact is highest and the effort is lowest: add real alt text and properly associated form labels, fix colour contrast, make the whole site operable by keyboard with a visible focus indicator, and set the page language in the markup. Those few fixes resolve a large share of the most common failures, and they are the ones a screen-reader or keyboard user notices first — so they buy the most real accessibility per hour spent before you work through the rest of the criteria.

There is an upside worth naming: this work pays for itself beyond compliance. The same semantic structure, clear alt text and faster, cleaner pages that make a site accessible also improve its SEO and its usability for everyone (Webability, 2026). That overlap is the whole argument for building accessibility into the code from the start — the case our pillar on whether web accessibility is the law makes from the regulatory side. The checklist above is how you act on it.