What WCAG AA Means for Your Nonprofit Website

WCAG (Web Content Accessibility Guidelines) is the international standard for digital accessibility. Level AA is the standard that matters for nonprofit organisations: it’s the level that UK equality law effectively requires, that the European standard EN 301 549 is built on, and that institutional funders are increasingly evaluating during due diligence.

WCAG AA compliance is not a design preference. It’s 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.

This guide covers how WCAG AA compliance works on Webflow specifically, what the framework handles, what requires manual attention, and how to maintain compliance as an ongoing governance practice.

What I Settle at Build Time

I build all nonprofit Webflow sites on the Lumos framework, which fixes the class and component conventions a build follows. Lumos is a class and component system, and no framework 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, so what follows is my build standard, applied on top of that system. Built this way, the most expensive structural failures are settled before any content goes in:

  • Semantic HTML structure: I build correct heading hierarchy (H1 → H2 → H3), landmark regions (nav, main, footer), and semantic elements used throughout. This means screen readers can navigate the page structure logically.
  • Keyboard navigation: I make every interactive element reachable and operable via keyboard. Focus states are visible. Tab order follows the visual layout. Skip-to-main-content links are built in.
  • Focus management: I write modals and overlays so they trap focus correctly. When an overlay closes, focus returns to the trigger element. Dropdown menus are keyboard-navigable.
  • Responsive behaviour: I build so 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, I add them on custom components and interactive widgets, with ARIA roles, states and properties applied correctly.

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.

What Requires Manual Attention

Even on a site built to an accessible standard, content-level accessibility requires ongoing human attention. The framework cannot know what your images mean or whether your link text is descriptive. These are the areas that need consistent editorial discipline:

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.

In Webflow, alt text belongs on the image asset and every instance of it inherits that text: in the Assets panel, click the cog on the image and fill the Descriptive field, or click Decorative for an image that carries no meaning. To override one instance, select it on the canvas and switch the Alt text dropdown to Custom description or Decorative. The same dropdown sits behind the wrench icon on an image inside a Rich Text element.

CMS images are the case that catches people out: alt text is not automatically a field on the collection item. Add a Plain text field to the Collection, fill it in on every item, then bind it through the Alt text dropdown on the image element. Where a Rich Text element draws its images from a rich text field, the alt text is set inside that field.

Common failures: missing alt text entirely, 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 (causing screen readers to 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 or browser developer tools. The most common failures on nonprofit sites: light grey text on white backgrounds, text overlaid on photographs without sufficient contrast, and link colours that don’t 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 just placeholder text, which disappears on focus). Error messages must be descriptive and associated with the relevant field. Forms must be completable by keyboard alone.

In Webflow, ensure every input has a label element linked to it. If using custom form styling, verify that the label association is maintained in the rendered HTML.

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.

Testing Your Site

Automated Testing

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’re essential for baseline monitoring but insufficient for compliance on their own.

  • axe DevTools: Free browser extension. Run on any page to get a list of violations with severity levels and remediation guidance. This should be your monthly monitoring tool.
  • WAVE: Free browser extension from WebAIM. Provides a visual overlay showing accessibility issues in context on the page.
  • Lighthouse: Built into Chrome DevTools. Includes an accessibility score based on automated checks.

Manual Testing

Everything the scan cannot see requires manual testing:

  • Keyboard navigation: Press Tab through the entire page. Can you reach every interactive element? Is focus visible? Can you operate menus, forms, and buttons without a mouse?
  • 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.

Before You Start

You do not need technical expertise to run a basic accessibility audit. You do need a laptop with Chrome or Firefox, some uninterrupted time, and the willingness to test your own site as a user with a disability would experience it.

Step 1: Test Keyboard Navigation

Close your mouse. Using only the keyboard, navigate your homepage from top to bottom using the Tab key to move forward and Shift+Tab to move backward.

Check for these specific issues:

Can you reach every interactive element? Every link, button, form field, and navigation item should be reachable by Tab. If you cannot Tab to something, keyboard users cannot access it.

Can you see where you are? As you Tab through the page, there should be a visible focus indicator (typically an outline or highlight) showing which element is currently selected. If the focus indicator is invisible or barely visible, users who rely on keyboard navigation cannot tell where they are on the page.

Does the Tab order make sense? Focus should move through the page in a logical reading order, typically left to right, top to bottom. If focus jumps around unpredictably, the page structure has issues.

Can you operate the navigation? Can you open dropdown menus with Enter or Space, navigate within them with arrow keys, and close them with Escape? If not, the navigation is inaccessible to keyboard users.

Can you complete the donation flow? Tab through your entire donation process. If you cannot complete a donation using only the keyboard, you are excluding donors with motor impairments.

Repeat this test on your donation/contact page and at least one programme page.

Step 2: Interpret and Prioritise Results

You will have a list of issues from the automated scans and manual testing. Not all issues are equal. Prioritise in this order:

Critical and serious automated violations. These are the issues that completely block access for some users. Missing form labels, broken keyboard navigation, and absent alt text on meaningful images fall here. Fix these first.

Keyboard navigation failures. If users cannot navigate or complete key tasks by keyboard, the site is fundamentally inaccessible regardless of what the automated scan says. This is often a structural issue requiring changes to the site’s framework or navigation component.

Colour contrast failures. These affect a wide range of users (including people with low vision, colour blindness, and anyone using a screen in bright conditions). They are also among the easiest to fix, typically requiring nothing more than CSS colour value changes.

Content-level issues. Missing alt text, unclear link text, and heading hierarchy problems. These are maintenance tasks that can be addressed incrementally as content is reviewed.

Moderate and minor automated violations. Address these after the critical issues are resolved. They represent genuine accessibility improvements but are lower risk.

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, with most being content-level issues (alt text, contrast on specific elements) rather than structural failures.

For a website built without accessibility consideration, automated scans frequently return many more violations per page, including structural issues that cannot be fixed by content changes alone. 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’s 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: Any new page template, navigation change, or component addition should be tested before going live.

For how to conduct the full audit, see Technical SEO Audit for Nonprofits which covers accessibility alongside other technical checks.

For the governance context behind accessibility investment, see WCAG Accessibility as a Nonprofit Governance Obligation.

If you want to assess where your site stands before committing to remediation, the Blueprint Audit includes a full WCAG AA accessibility assessment as part of the technical review.

Further Reading