Why Accessibility Isn't Optional for Nonprofits

Most nonprofits include accessibility in their values. Many fewer ensure their website is actually accessible. That gap matters — both because an inaccessible website excludes people your organisation might exist to serve, and because WCAG AA compliance is increasingly a legal and funding requirement, not just a best practice.

This guide covers what WCAG AA means in practice for a nonprofit website, how to test for compliance, and how Webflow's tooling supports (or complicates) accessible builds.

What WCAG AA Actually Requires

WCAG stands for Web Content Accessibility Guidelines. It's produced by the W3C (World Wide Web Consortium) and is the international standard for web accessibility. The three conformance levels are A (minimum), AA (standard), and AAA (enhanced).

WCAG AA is the target for most organisations. It's the level required for UK public sector bodies under the Public Sector Bodies Accessibility Regulations 2018, and it's the benchmark most funders and accessibility auditors reference.

WCAG is organised around four principles: content must be Perceivable, Operable, Understandable, and Robust (POUR). Within these, there are 13 guidelines and 50 success criteria at level A and AA combined.

The practical requirements that matter most for nonprofit websites:

Perceivable

• Images have text alternatives (1.1.1): Every informative image needs descriptive alt text. Decorative images should have empty alt attributes (alt="") so screen readers skip them.
• Captions for video (1.2.2): Pre-recorded video content needs captions.
• Content can be presented differently (1.3): Structure should be communicated through markup, not just visual styling. Headings should be proper heading elements, not just large bold text.
• Sufficient colour contrast (1.4.3): Text needs a contrast ratio of at least 4.5:1 against its background (3:1 for large text). This is one of the most commonly failed criteria.
• Text can be resized (1.4.4): Text should be resizable up to 200% without loss of content or functionality.
• No content relies on colour alone (1.4.1): Information can't be conveyed only through colour (e.g., red for required fields must also have another indicator).

Operable

• All functionality available via keyboard (2.1.1): Every interactive element — menus, buttons, forms, modals — must be operable with a keyboard alone. This is fundamental for screen reader users and people who can't use a mouse.
• No keyboard traps (2.1.2): Keyboard focus can't get stuck anywhere on the page.
• Skip navigation link (2.4.1): A mechanism to skip repeated blocks of content (like navigation menus) and jump straight to main content.
• Page has a title (2.4.2): Every page needs a descriptive title in the <title> tag.
• Focus order makes sense (2.4.3): Keyboard focus moves through the page in a logical order.
• Link purpose clear from context (2.4.4): Link text — or link text plus surrounding context — must describe where the link goes. "Click here" and "Read more" fail this criterion.
• Focus is visible (2.4.7): Keyboard focus must be visually indicated. Removing the browser's default focus outline without providing an equivalent is a common failure.

Understandable

• Language of page declared (3.1.1): The HTML lang attribute must be set correctly.
• Consistent navigation (3.2.3): Navigation should be consistent across pages.
• Error identification (3.3.1): Form errors must be identified and described in text, not just through colour or icon.
• Labels for inputs (3.3.2): All form inputs must have visible, programmatically associated labels.

Robust

• Valid markup (4.1.1): HTML should be well-formed. Duplicate IDs, unclosed tags, and parsing errors can cause assistive technologies to malfunction.
• Name, role, value for all UI components (4.1.2): Interactive elements must communicate their purpose, role, and state to assistive technologies — typically via ARIA attributes when native HTML semantics aren't sufficient.
• Status messages programmatically determinable (4.1.3): Messages that convey information — form submission confirmations, error messages, loading states — must be communicated to assistive technologies even if focus doesn't move to them.

How to Test for WCAG AA Compliance

Automated testing tools can identify around 30% of WCAG failures. The remaining 70% require manual testing and judgement. Both are necessary.

Automated Testing

• WAVE (wave.webaim.org): Browser extension that overlays accessibility information directly on your page. Good for a quick visual check.
• Axe DevTools: Browser extension that runs within Chrome/Firefox DevTools. More detailed than WAVE and better for developer workflows.
• Lighthouse: Built into Chrome DevTools. Includes an accessibility audit alongside performance and SEO checks.
• Accessibility Insights: Microsoft's free tool. The "FastPass" mode checks the most common issues; "Assessment" mode guides you through a complete manual check.

Manual Testing

After automated testing, manual checks are essential for the criteria automated tools can't assess:

• Keyboard navigation: Tab through the entire page. Can you reach every interactive element? Does focus order make sense? Is focus always visible?
• Screen reader testing: Use NVDA (Windows, free) or VoiceOver (Mac, built-in) to navigate the page. Does the content make sense without visual context? Are images described? Are forms labelled correctly?
• Colour contrast: Use a contrast checker like WebAIM's Contrast Checker or the Colour Contrast Analyser desktop app to verify text/background combinations, including on hover states and focus states.
• Resize text to 200%: In browser settings, increase text size to 200%. Does content remain readable and functional, or does it break?
• Zoom to 400%: For WCAG 2.1 Reflow criterion (1.4.10, not covered here but increasingly expected), content should be usable at 400% zoom without horizontal scrolling.

Webflow-Specific Accessibility Considerations

Heading Structure

Webflow allows you to style any element however you want, which means it's easy to make a paragraph look like a heading without making it function like one. Screen readers and search engines navigate by heading structure — headings must be Heading elements (H1–H6) set at the correct level in the element settings panel, not just styled to look large.

Focus Indicators

Webflow's default styles often suppress the browser's native focus outline for aesthetic reasons. If your design removes the default focus ring, you must replace it with an equivalent — a visible, high-contrast focus indicator on all interactive elements. This is commonly done via a global CSS class applied to focus states.

Interactive Elements and ARIA

Webflow's native elements (buttons, links, form fields) have reasonable accessibility defaults. Custom interactions — accordions, tabs, modals built with Webflow Interactions or custom code — often lack the ARIA attributes needed for screen reader users to understand what's happening.

When building interactive components in Webflow, add appropriate ARIA attributes:

• Accordions: aria-expanded on triggers, aria-controls linking trigger to content
• Modals: role="dialog", aria-modal="true", focus management on open/close
• Tabs: role="tablist", role="tab", role="tabpanel", aria-selected

In Webflow, custom attributes are added via the element settings panel under Custom Attributes. They can also be managed via Webflow's API for programmatic control.

Form Labels

Webflow's form builder includes visible labels by default. Ensure labels are programmatically associated with their inputs via the for/id relationship — not just visually adjacent. Placeholder text is not a substitute for a label; placeholders disappear on input and aren't reliably communicated by all screen readers.

Image Alt Text

Alt text can be set on image elements in Webflow's settings panel. For CMS images, alt text should be a required CMS field — not optional — to prevent blank alt attributes on published content.

Animations and Motion

WCAG 2.1 criterion 2.3.3 (AAA) and the related 2.3.1 (AA) address content that flashes or moves. Beyond the flashing threshold, best practice for any site using Webflow Interactions or GSAP animations is to respect the prefers-reduced-motion media query. Users who have enabled reduced motion in their OS settings should experience reduced or eliminated animations.

In CSS: @media (prefers-reduced-motion: reduce) { ... }

Accessibility Statements

UK public sector bodies are legally required to publish an accessibility statement. For other nonprofits, publishing one is best practice and increasingly expected by funders.

An accessibility statement should include:

• Your current compliance status (fully compliant, partially compliant, not compliant)
• Known accessibility issues and when you plan to address them
• How to contact you to report accessibility problems
• A reference to the enforcement procedure (EHRC in England, Scotland, and Wales)

The Government Digital Service provides a sample accessibility statement template that's a reasonable starting point for any nonprofit.

Integrating Accessibility into Webflow Projects

Accessibility is significantly harder to retrofit than to build in from the start. The most efficient approach is to establish accessible patterns — focus styles, heading structure, form labelling, ARIA on interactive components — at the beginning of a project and apply them consistently.

When I use the Lumos framework for Webflow builds, accessibility is built into the design system rather than applied page by page. Global focus styles, semantic heading hierarchy, and labelled form components become defaults rather than manual additions.

For existing sites being assessed, the Blueprint Audit includes a WCAG AA accessibility review as part of its scope — identifying failures, prioritising by impact, and providing a remediation roadmap.

For the pre-launch checklist that includes accessibility testing, see my nonprofit website pre-launch checklist. For the broader technical context in which accessibility sits, see the technical SEO audit guide — accessibility and SEO are closely related in practice, with heading structure, alt text, and semantic markup serving both simultaneously.