Website Accessibility Testing: A Complete Guide to WCAG 2.2 Compliance

Accessibility gets treated as a checkbox at the end of a project, if it gets treated at all. That's backwards on every count that matters: it's a real legal exposure, it's a usability problem for a meaningful share of your visitors, and most of the fixes are cheap if you catch them early.

Why This Actually Matters

• Legal risk is real and growing - ADA-related web accessibility lawsuits in the US number in the thousands per year, and most target small-to-midsize businesses, not just large enterprises.
• It affects more visitors than you think - roughly 1 in 6 people worldwide live with some form of disability, and many more are affected temporarily (a broken arm, bright sunlight on a phone screen, a noisy environment).
• Most fixes double as good UX - better contrast, clearer focus states, and sensible heading structure make a site easier to use for everyone, not just screen reader users.

Understanding WCAG Conformance Levels

WCAG (Web Content Accessibility Guidelines) defines three conformance levels, and knowing which one you're actually targeting matters:

• Level A - the bare minimum. Missing this level means fundamental barriers exist for some users.
• Level AA - the practical, widely-adopted target. Most legal standards and corporate policies reference AA specifically.
• Level AAA - the highest level, but not realistically achievable for all content on most sites (some AAA criteria conflict with normal design decisions).

Unless you have a specific reason otherwise, WCAG 2.2 Level AA is the target worth aiming for.

The Four Principles (POUR)

WCAG is organized around four principles - most specific criteria trace back to one of these:

• Perceivable - can users perceive the content, regardless of sense? (alt text for images, captions for video, sufficient color contrast)
• Operable - can users operate the interface, regardless of input method? (full keyboard access, no seizure-inducing flashing, enough time to complete actions)
• Understandable - is the content and interface predictable and clear? (consistent navigation, clear error messages, readable language)
• Robust - does it work reliably across browsers and assistive technologies? (valid semantic HTML, correct ARIA usage)

Issues That Show Up on Almost Every Site

• Images with missing or unhelpful alt text (or decorative images missing alt="", forcing screen readers to announce meaningless filenames)
• Text/background color combinations that fail the 4.5:1 contrast ratio for normal text (3:1 for large text)
• Interactive elements unreachable by keyboard alone - custom dropdowns, modals, and carousels are the usual offenders
• Form inputs with placeholder text standing in for a real <label>, which disappears the moment a user starts typing
• Focus indicators stripped via outline: none with nothing put in their place
• Heading levels used for visual size rather than document structure (jumping from H1 straight to H4)
• Buttons and links with no accessible name - an icon-only button with no aria-label reads as "button" to a screen reader, nothing more

WCAG 2.2 Checklist: The New Success Criteria

WCAG 2.2 became a W3C Recommendation in October 2023. It keeps everything in WCAG 2.1, removes 4.1.1 Parsing, and adds nine success criteria. Use this WCAG 2.2 checklist to cover what changed:

Criterion	Level	What to check
2.4.11 Focus Not Obscured (Minimum)	AA	A focused element is never fully hidden behind sticky headers, cookie banners or chat widgets
2.4.12 Focus Not Obscured (Enhanced)	AAA	No part of the focused element is hidden
2.4.13 Focus Appearance	AAA	The focus indicator is large enough and has enough contrast
2.5.7 Dragging Movements	AA	Anything done by dragging (sliders, sortable lists, maps) also works with a single click or tap
2.5.8 Target Size (Minimum)	AA	Click and tap targets are at least 24 by 24 CSS pixels, or have enough spacing
3.2.6 Consistent Help	A	Help links, contact details or chat appear in the same place on every page
3.3.7 Redundant Entry	A	Users are not asked to re-enter information they already gave in the same process
3.3.8 Accessible Authentication (Minimum)	AA	Login does not depend on a cognitive test such as solving a puzzle or remembering a password, unless an alternative or help (like paste or password managers) is allowed
3.3.9 Accessible Authentication (Enhanced)	AAA	No cognitive function test at all, even object recognition

Most legal and procurement requirements target Level AA, so the six A and AA items above are the ones to prioritize. Run an accessibility audit for the automatable checks, then test focus visibility, dragging alternatives and login flows by hand.

Automated Testing Has a Real Ceiling

This is worth being honest about: automated accessibility scanners, including ours, reliably catch roughly a third of WCAG success criteria - things like missing alt text, contrast failures, and missing form labels. They cannot evaluate whether alt text is actually meaningful, whether a complex interaction genuinely works with a screen reader, or whether reading order makes sense.

That doesn't make automated scanning useless - it catches the highest-volume, easiest-to-fix issues instantly and continuously. It means automated scanning is a floor, not a ceiling. Real conformance also needs some manual keyboard-only navigation and, ideally, actual screen reader testing (VoiceOver on Mac/iOS and NVDA on Windows are both free).

A Practical Testing Checklist

• Run an automated scan first - fix everything it finds before spending manual time on anything else
• Unplug your mouse and navigate the whole page using only Tab, Shift+Tab, and Enter
• Check that focus is always visible and the tab order matches the visual layout
• Check color contrast on every distinct text/background combination, not just body copy
• Turn on a screen reader and listen to your homepage and your main conversion flow (signup, checkout, contact form)
• Verify every form field announces a clear label and any validation errors are announced, not just shown visually