WCAG 2.2 AA is the level of the Web Content Accessibility Guidelines that a charity or nonprofit website should be measured against. Meeting it takes two kinds of work: structure, which is settled when the site is built, and content, which your team keeps checking for as long as the site exists. This guide says which is which, and how to test both.

What WCAG 2.2 AA Means for a Charity Website

Level AA is the standard that matters for nonprofit organisations: it is the benchmark a website is judged against under UK equality law, the level the European standard EN 301 549 is built on, and the level institutional funders are increasingly evaluating during due diligence.

WCAG AA compliance is not a design preference. It is a governance obligation. An inaccessible website excludes donors, beneficiaries, Board members and stakeholders with disabilities, and it creates regulatory exposure that the Board has fiduciary responsibility to manage. That argument is made in full in Website Accessibility for Nonprofits. This guide covers the checks.

The WCAG 2.2 AA Standards the Build Settles

No platform makes a site accessible on its own. Accessibility is a property of how a site is built rather than of what it is built on. This is why I build on a framework rather than a theme. I use Lumos, which fixes the structural and naming conventions up front, though no framework does the job alone: what follows is my build standard, applied on top of it. On a site someone else built, this is the list to ask them about.

  • Semantic HTML structure: Correct heading hierarchy (H1, then H2, then H3), landmark regions (nav, main, footer) and semantic elements throughout, so screen readers can navigate the page structure logically.
  • Keyboard navigation: Every interactive element is reachable and operable by keyboard. Focus states are visible, tab order follows the visual layout, and skip-to-main-content links are built in.
  • Focus management: Modals and overlays trap focus correctly, and focus returns to the trigger element when they close. Dropdown menus are keyboard-navigable.
  • Responsive behaviour: Content reflows without scrolling in two dimensions down to 320 CSS pixels, which is what 1.4.10 Reflow (Level AA) requires. Pointer targets meet the 24 by 24 CSS pixel floor in 2.5.8 Target Size (Minimum), also Level AA and new in WCAG 2.2.
  • ARIA attributes: Where native HTML semantics are insufficient, custom components and interactive widgets carry the correct ARIA roles, states and properties.

These structural elements are the most expensive to retrofit on an existing site. Settling them at build time shifts the ongoing compliance work from structural remediation to content-level maintenance.

The WCAG 2.2 AA Requirements Your Team Must Keep Meeting

A framework cannot know what your images mean or whether your link text is descriptive. These areas need consistent editorial discipline on any site, however well it was built.

Image Alt Text

Every meaningful image needs a descriptive alt attribute that conveys the image's purpose in context. This is 1.1.1 Non-text Content, which is Level A, so it sits below the AA bar rather than in it. Decorative images need an empty alt attribute (alt="") so screen readers skip them.

Check that your CMS has somewhere to put alt text for images that come from a content type, such as news posts or team profiles.

Common failures: missing alt text, alt text that describes the image literally rather than its purpose ("photo of people" vs "programme participants at the Manchester workshop"), and decorative images with descriptive alt text, which makes screen readers announce irrelevant information.

Colour Contrast

1.4.3 Contrast (Minimum), which is Level AA, requires a ratio of at least 4.5:1 for normal text and 3:1 for large text. WCAG defines large scale text as at least 18 point, or 14 point bold. Those are points, not pixels: roughly 24px and 18.7px, so a heading set at 18px is still normal text and still needs 4.5:1. This applies to all text on the site, including text on coloured backgrounds, text on images, button text and link text.

Check contrast using the WebAIM Contrast Checker. The most common failures on nonprofit sites: light grey text on white backgrounds, text overlaid on photographs, and link colours that do not meet the ratio against their background.

Link Text

Links should be descriptive out of context. "Click here" and "read more" fail because a screen reader user navigating by links hears a list of meaningless phrases. Instead: "Read the annual report" or "Contact the programmes team."

Form Accessibility

Every form field needs a visible label, not placeholder text alone, which disappears on focus. Error messages must be descriptive and associated with the relevant field. Forms must be completable by keyboard alone. If a form has custom styling, check that each label is still linked to its input on the published page.

Video and Audio

Video content needs captions. Audio content needs transcripts. Captions must be synchronised and accurate, which means auto-generated captions have to be reviewed and corrected.

A WCAG 2.2 AA Checklist for Testing Your Site

Automated tools catch a minority of WCAG issues. When the Government Digital Service ran ten of them against 143 deliberately introduced barriers, the best found 41% counting its manual inspection prompts, and 29% were missed by every tool tested. They are essential for baseline monitoring but insufficient for compliance on their own.

Run the automated tools:

  • axe DevTools: Free browser extension. Lists violations with severity levels and remediation guidance. This should be your monthly monitoring tool.
  • WAVE: Free browser extension from WebAIM. Shows accessibility issues in context on the page.
  • Lighthouse: Built into Chrome DevTools. Includes an accessibility score based on automated checks.

Then test by hand what the scan cannot see:

  • Keyboard navigation: Put the mouse away and work through the page and the donation flow. How to Test Keyboard Navigation on Your Charity Website lists the keys and what to check.
  • Screen reader testing: Test with NVDA (Windows, free) or VoiceOver (Mac, built-in). Navigate the homepage. Can you understand the page structure? Are images described? Are forms usable?
  • Heading hierarchy: Install the HeadingsMap browser extension and verify the heading structure is logical and sequential on every page template.

How to Prioritise What You Find

Not all issues are equal. Work in this order:

  1. Critical and serious automated violations. These block access for some users completely. Missing form labels, broken keyboard navigation and absent alt text on meaningful images fall here.
  2. Keyboard navigation failures. If users cannot complete key tasks by keyboard, the site is fundamentally inaccessible whatever the scan says. This is often a structural issue requiring changes to the site's framework or navigation component.
  3. Colour contrast failures. These affect a wide range of users, including people with low vision or colour blindness and anyone using a screen in bright conditions. They are also among the easiest to fix, typically needing a colour value changed.
  4. Content-level issues. Missing alt text, unclear link text and heading hierarchy problems. Address these incrementally as content is reviewed.
  5. Moderate and minor automated violations. These are genuine improvements but lower risk, so they come after the critical issues are resolved.

What a Good Baseline Looks Like

For a nonprofit website built to an accessible standard, you should see few violations per page on the automated scan, mostly content-level issues (alt text, contrast on specific elements) rather than structural failures.

A website built without accessibility consideration frequently returns many more, including structural issues that content changes cannot fix. That is not unusual: the 2026 WebAIM Million detected an average of 56.1 errors on a home page across a million sites, and found WCAG 2 failures on 95.9% of them. In these cases, the audit findings become evidence for a rebuild recommendation rather than a remediation plan.

Maintaining Compliance Over Time

Accessibility is not a one-time project. New content, new pages and platform updates can all introduce failures. The governance cadence I recommend:

  • Monthly: Run axe DevTools on the homepage. Note the violation count and trend. If it is increasing, investigate.
  • Quarterly: Run axe on three key pages (homepage, programme page, donation page). Manual keyboard test on the donation flow. Review alt text on recently published content.
  • Annually: Full manual accessibility audit across all page templates. Screen reader testing. Contrast review. Update the accessibility statement with findings.
  • After significant site changes: Test any new page template, navigation change or component before it goes live.

For how to conduct the full audit, see Technical SEO Audit for Nonprofit Websites, which covers accessibility alongside other technical checks. To assess where your site stands before committing to remediation, the Blueprint Audit includes a full WCAG 2.2 AA assessment as part of the technical review.

On Webflow? The platform-specific steps are in Platform Notes.

Next Step

Start with the check that needs no software: How to Test Keyboard Navigation on Your Charity Website.

Related resources: