WCAG AA Accessibility on Webflow: What Nonprofits Need to Implement

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 Accessibility Act references via EN 301 549, 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 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 the Lumos Framework Handles

I build all nonprofit Webflow sites on the Lumos framework (v2.2.0+). Lumos provides an accessible foundation that eliminates the most expensive structural accessibility failures:

• Semantic HTML structure: 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: All interactive elements are 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: Modals and overlays trap focus correctly. When an overlay closes, focus returns to the trigger element. Dropdown menus are keyboard-navigable.
• Responsive behaviour: Content reflows at all viewport sizes without horizontal scrolling. Touch targets meet minimum size requirements on mobile.
• ARIA attributes: Where native HTML semantics are insufficient (custom components, interactive widgets), ARIA roles, states, and properties are correctly applied.

These structural elements are the most expensive to retrofit on an existing site. Building on Lumos means they’re present from the start, which shifts the ongoing compliance work from structural remediation to content-level maintenance.

What Requires Manual Attention

Even on an accessible framework, 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. Decorative images need an empty alt attribute (alt="") so screen readers skip them.

In Webflow, alt text is set when the image is uploaded or in the image element settings. For CMS-driven content, alt text is a field on the collection item.

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

WCAG AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18px+ or 14px+ bold). 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 — auto-generated captions should be reviewed and corrected.

Testing Your Site

Automated Testing

Automated tools catch approximately 30–40% of WCAG issues. 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

The remaining 60–70% of WCAG issues require 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.

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 the accessibility statement your organisation needs, see Accessibility Statement Template for Nonprofits.

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.

Before You Start

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

An automated scan catches roughly 30–40% of WCAG violations. The rest require manual testing — checking keyboard navigation, reading order, focus management, and whether content makes sense without visual context. Both are necessary.

Step 3: 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 5: 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 the largest number 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 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 on an accessible framework like Webflow with Lumos, you should see fewer than 10 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 30–80+ violations per page, including structural issues that cannot be fixed by content changes alone. In these cases, the audit findings become evidence for a rebuild recommendation rather than a remediation plan.

Further Reading

• Accessibility Statement Template for Nonprofits
• Nonprofit Website Pre-Launch Checklist
• CookieYes and Google Consent Mode V2 for Webflow Nonprofit Sites