A WCAG 2.2 AA compliance checklist is most useful before a site is signed off, not after a customer reports that they cannot complete a form. Accessibility defects are often inexpensive to prevent in design and development, but awkward to fix once components, content and third-party tools are already live.
For founders and product teams, WCAG is not a box-ticking exercise for developers. It affects whether people can find information, understand an offer, create an account, make an enquiry or use a service without unnecessary friction. The same decisions often improve usability for everyone: clear labels, visible focus states, sensible form errors and controls that work properly on a mobile device. For the wider picture beyond this checklist, see our guide on what makes a website accessible in practice.
WCAG 2.2 is the current version of the Web Content Accessibility Guidelines. AA is the practical target most organisations set for public-facing websites and web applications. It includes every applicable Level A and Level AA success criterion. That wording matters: a marketing site, logged-in product and native mobile app will not have exactly the same risks.
How to use this WCAG 2.2 AA compliance checklist
Test real user journeys, rather than reviewing isolated pages. On a brochure site, that might mean finding a service, using the contact form and reading an article. In a SaaS product, it should include registration, password reset, core tasks, billing-related screens and support routes.
Automated testing is a useful first pass on any web accessibility checklist. It can flag missing labels, invalid ARIA use, weak colour contrast and heading problems quickly. It cannot tell you whether a page makes sense when read aloud, whether keyboard focus moves logically, or whether an error message explains what to do next. Manual testing is where those failures appear.
Start with a representative set of templates and components, then test every variation that changes behaviour. A single well-built button component is helpful. A button component that looks the same but behaves differently in a modal, table and mobile menu still needs separate checks.
Page structure and content
A page should communicate its purpose and structure without relying on visual styling alone. Screen-reader users commonly navigate by headings, landmarks, links and form controls, so those patterns need to be meaningful.
Check that each page has a unique, descriptive title and a language declaration. Use one clear page heading, then nest subsequent headings in a logical order. Do not choose heading levels because they produce a preferred font size. Style headings with CSS while preserving their semantic level.
Text needs sufficient contrast against its background: generally 4.5:1 for normal text and 3:1 for large text. Placeholder text, disabled controls and text over images are common weak spots. If a hero image changes by campaign or screen size, test every version rather than approving one desktop screenshot.
Links should describe their destination or action. A page full of repeated “Read more” links is harder to navigate out of context. Images need useful alternative text when they convey information; decorative images should be ignored by assistive technology rather than given a filename or a vague label such as “image”.
Do not use colour as the only way to show status, required fields or selected options. A red border around an invalid input is not enough. Pair it with clear text, an icon with an accessible name, or both.
Keyboard access and visible focus
Every function must work with a keyboard alone. That includes navigation menus, cookie controls, search, filters, dialogs, carousels, date pickers, embedded tools and account settings. Press Tab, Shift+Tab, Enter, Space and Escape through key journeys without using a mouse.
The tab order should follow the visual and task order. A keyboard user should not jump from a header into hidden content, get trapped inside a menu, or tab through controls that are not currently visible. When a dialog opens, focus should move into it; when it closes, focus should return to the control that opened it.
Focus must always be visible. WCAG 2.2 adds a Level AA requirement that keyboard focus is not completely hidden by sticky headers, cookie banners, chat widgets or floating action buttons. This is easy to miss on smaller screens, where fixed elements occupy more of the viewport.
Avoid removing outlines without supplying a clear replacement. A subtle change in background colour is rarely enough, particularly in high-glare conditions or for users with low vision. Focus indicators should have adequate contrast and remain obvious across every theme and component state.
Forms, authentication and errors
Forms are where accessibility and conversion meet. A user who cannot understand an error or complete a verification step is unlikely to try again.
Give each input a persistent visible label. Placeholder text may provide an example, but it disappears when the user starts typing and is not a replacement for a label. Group related controls, such as radio buttons, under a meaningful legend, and explain format requirements before the user submits where possible.
When validation fails, identify the field in error, explain the problem in plain language and keep the entered data. For example, “Enter a postcode in the format SW1A 1AA” is more useful than “Invalid input”. On longer forms, provide an error summary that receives appropriate attention while still allowing the user to reach each affected field.
WCAG 2.2 also requires teams to avoid making people enter the same information twice within the same process when it can be reused or selected. This applies to things such as an address already entered earlier in a journey. There are legitimate exceptions, including security and data-validation needs, but duplication should be a deliberate choice rather than an accidental product limitation.
Authentication deserves special scrutiny. A login should not require a user to solve a cognitive test, remember an image pattern or transcribe text from an image unless an accessible alternative is available. Password managers and paste should work. Blocking paste into password fields may feel like a security measure, but it creates a barrier and rarely delivers the intended benefit.
Touch, mobile and interactive components
A responsive layout is not automatically accessible on a phone. Test with zoom, text enlargement, device rotation and touch interaction, especially where controls are close together.
WCAG 2.2 introduces two requirements that affect modern interfaces directly. If an action relies on dragging, such as reordering cards or moving an item on a board, provide a simple alternative such as move-up and move-down buttons. If a small target can be activated by touch, ensure there is enough space around it. The general minimum target size is 24 by 24 CSS pixels, though the criterion has defined exceptions for inline text, browser-controlled controls and cases where equivalent larger targets are available.
Do not rely on hover to reveal essential information or controls. Tooltips, card actions and menus need a touch and keyboard-friendly route. Any content that appears on hover or focus should be dismissible, remain visible while users move towards it, and not disappear before it can be read.
For custom controls, use native HTML first. A native button, input or select brings keyboard behaviour and accessibility information with it. Custom widgets can be justified when the product genuinely needs them, but they require careful engineering: correct roles, names, states, keyboard interactions and testing with assistive technology. Adding ARIA labels to a non-semantic clickable div is not an equivalent substitute. Our web and app development services build interactive components this way by default, rather than retrofitting accessibility once a design is finished.
Consistency, media and time limits
Keep repeated navigation and help options in a consistent location and order. WCAG 2.2 specifically addresses consistent help: if contact, self-help or chat options appear across a process, users should be able to find them in the same relative place unless a user changes the layout themselves.
Captions are required for pre-recorded video with audio. Audio descriptions, transcripts and other alternatives depend on the media and the criterion being assessed, but the practical question is straightforward: can someone who cannot see or hear part of the media still get its essential meaning?
Give users control over moving, flashing or automatically updating content. Avoid auto-advancing carousels where possible. For sessions with time limits, provide a warning and extension mechanism where the task allows it. Security-sensitive flows can have exceptions, but a short timer should never be the default answer to an interaction design problem.
Test the finished experience, not just the code
Before launch, review the following across your priority journeys:
- Navigate the full journey by keyboard, including menus, dialogs, errors and confirmation states.
- Check headings, landmarks, page titles, link text, image alternatives and language settings.
- Measure contrast in every state: default, hover, focus, disabled, error and dark or campaign variants.
- Complete forms with invalid, missing and previously entered information, then test password-manager and paste behaviour.
- Check mobile target sizes, zoomed layouts, drag alternatives and fixed elements that could cover focused controls.
- Test with at least one screen reader and more than one browser or device combination relevant to your audience.
Treat findings as product work, not a final polish pass. Some fixes are local, such as correcting an image alternative. Others expose a design-system problem, such as an inaccessible modal or button component used across the product. Fixing the underlying component is slower at first, but prevents the same defect returning on the next release.
A checklist cannot certify a site by itself, and website accessibility compliance is not a one-off launch task. New content, integrations and features can introduce regressions. Build checks into design review, pull requests and release testing, then revisit key journeys as the product changes.
If you need an independent view of an existing site, our website accessibility audit service walks through the real journeys that matter to your users, rather than just running an automated scan. If you want accessibility designed into a new build from the outset, book a free consultation and we’ll talk through what a WCAG 2.2 AA review would look like for your product.
