WCAG 2.2 AA Checklist for Government and Nonprofit Websites

WCAG 2.2 Level AA is the standard most public-sector and nonprofit solicitations point at, directly or through Section 508. The full specification is long and written for implementers. This is the working checklist — the things that actually fail on government and nonprofit sites, in the order they are worth checking.

It is not a substitute for testing. Automated tools catch a meaningful share of issues and miss the ones people complain about most, so treat this as the list you verify by hand.

Structure and navigation

Headings describe the content and do not skip levels. One h1 per page, then h2s and h3s in order. Screen-reader users navigate by heading; a page where headings were chosen for their font size is effectively unnavigable.

Landmarks are used properly. Header, nav, main, footer as real elements, so a keyboard user can skip straight to the content.

There is a skip link. The first thing a keyboard user encounters should let them jump past the navigation. Test it: press Tab on a fresh page load and see what happens.

Page titles are unique and descriptive. "Apply for a Residential Parking Permit — City of X" tells someone with twelve tabs open where they are. "Home" does not.

Keyboard operability

Everything works without a mouse. Tab through the entire page. Every link, button, form field, menu and modal must be reachable and operable.

Focus is always visible. You must be able to see where you are. A focus outline removed for aesthetic reasons is one of the most common failures on redesigned sites.

Nothing traps focus. Modals, carousels and embedded widgets must let you tab back out. Test the cookie banner specifically — it is frequently the first thing a keyboard user meets and frequently a trap.

Focus order follows reading order. If the visual layout puts the sidebar after the content but the DOM puts it first, keyboard users get a different page from everyone else.

Forms

This is where public-sector sites fail most often, and where failure has the highest cost, because forms are how residents actually transact.

Every field has a real label, programmatically associated with the input. Placeholder text is not a label; it disappears when typing starts.

Errors are announced, not just coloured. A red border communicates nothing to a screen-reader user. Errors need text, associated with the field, describing what to fix.

Required fields are marked in text, not only with a coloured asterisk.

Related fields are grouped with fieldset and legend, so "postal address" reads as one thing rather than five unrelated boxes.

Nothing submits on change. A dropdown that navigates the moment it is changed is unusable with a keyboard, because arrowing through options triggers each one.

Colour and contrast

Body text meets 4.5:1 against its background. Large text meets 3:1. Check the states as well as the default — hover, focus, visited, disabled and placeholder text are the ones that fail.

Interface components meet 3:1. Form borders, focus indicators and icon buttons are covered, not just text.

Colour is never the only signal. A required field, an error, a status or a chart series identified only by colour excludes colour-blind users. Add text, shape or pattern.

Images, media and documents

Meaningful images have meaningful alt text, and decorative ones have empty alt so screen readers skip them. "Image of a building" is not alt text.

Text is not baked into images. Hours, fees and deadlines set as graphics are invisible to assistive technology and to search — and to the AI assistants residents increasingly ask, which is covered in GEO for government websites.

Video has captions and, where the visuals carry information, audio description. Council meeting recordings are covered by this.

PDFs are assessed. A scanned PDF is an image of a document — unreadable to a screen reader. For key content, publish it as a web page and keep the PDF as a copy.

Zoom, reflow and motion

The page works at 200% zoom without horizontal scrolling or lost content.

Content reflows at 320px width — the mobile requirement stated in a way you can test on a desktop by narrowing the window.

Nothing moves automatically for more than five seconds without a way to pause it. Auto-advancing carousels on homepages are the usual offender.

What WCAG 2.2 added

If you last checked against 2.1, these are the newer criteria worth a specific look:

Focus is not obscured. A sticky header or floating chat widget must not cover the element you have just tabbed to. Very common on redesigned sites with sticky navigation.

Dragging has an alternative. Anything operated by dragging needs a single-pointer alternative — relevant to map tools and reordering interfaces.

Targets are at least 24 by 24 CSS pixels, or adequately spaced. Icon-only buttons and tightly packed footer links are the usual failures.

Help stays in the same place. If contact or help links appear across pages, keep them in a consistent position.

Do not make people re-enter information they have already provided in the same process, and do not require a cognitive test — like remembering a code from an earlier step — to complete a task.

How to actually test this

Run an automated scan across the whole site to catch systematic failures. Then, on your three most important journeys — usually apply, pay and contact — do a manual pass: complete the whole journey with the keyboard only, then again with a screen reader, then again at 200% zoom.

Those three passes on three journeys will tell you more than any report. If you want it done independently and documented, that is what an accessibility audit is, and the findings are useful evidence when you need to fund the fix.

One thing to avoid

Accessibility overlay widgets do not achieve conformance. They cannot repair heading order, unlabelled fields, focus traps or contrast in the underlying markup, and they have been named in accessibility litigation. If a vendor proposes one as the solution, that tells you they have not scoped the real work — see how to evaluate proposals.