For most nonprofits, the website is the program: it’s where people donate, register for services, apply for help, and learn what you do. So when a part of that site doesn’t work for someone using a screen reader or navigating by keyboard, the cost isn’t abstract. A blind donor who can’t complete the gift simply leaves — and you never see the lost revenue in your analytics. Web accessibility for nonprofits is, before it is anything legal, a mission and fundraising problem.

It’s also a widespread one. In the WebAIM Million 2025 analysis of the top one million home pages, 94.8% had detectable WCAG failures, averaging 51 errors per page. The most common issues map directly onto the parts of a charity site that matter most: low-contrast text (79.1% of pages), missing image alternative text (55.5%), and missing form input labels (48.2%) — the exact defect that breaks a donate form for assistive-technology users.

The donation form is where it hurts most

Walk through a typical “Give” page and you’ll find the highest-stakes interactions on the whole site stacked in one place: amount buttons, a custom-amount field, a “make this monthly” toggle, payment fields, and a submit. Each is a place accessibility quietly fails.

  • Amount selectors built as <div>s instead of real buttons or radio inputs can’t be reached or activated by keyboard.
  • Unlabeled fields (the 34.2% of form inputs WebAIM found without a programmatic label) leave a screen reader announcing “edit text, blank” where it should say “Donation amount, dollars.”
  • Recurring-gift toggles implemented as unlabeled switches give no indication of on/off state.
  • Inline validation errors that appear visually but aren’t announced strand users who don’t know why “Donate” did nothing.

None of this shows up in a casual sighted test, which is why it persists. Our guide to accessible forms walks through the label, focus-order, and error-handling patterns that make a donate flow completable by everyone — and the same fixes usually make it faster and clearer for your sighted donors too.

Funders increasingly require it

Accessibility is no longer just a values statement in a grant narrative — for many funding streams it’s a condition.

If your organization receives federal financial assistance, Section 504 of the Rehabilitation Act applies, alongside Section 508 for technology tied to federal programs (WebAIM’s plain-language overview is a good primer). The Department of Health and Human Services made this concrete: its 2024 Section 504 final rule sets an explicit WCAG 2.1 Level AA standard for the websites and apps of recipients of HHS funding — and after a one-year extension, the compliance deadlines now fall on May 11, 2027 for recipients with 15+ employees and May 10, 2028 for smaller ones. The parallel DOJ Title II web rule holds state and local governments to the same WCAG 2.1 AA bar, which matters for any nonprofit operating programs on a government’s behalf.

Beyond federal money, many private foundations and city/county grants embed nondiscrimination and digital-accessibility language in their terms. Building to WCAG 2.1 AA now means you can answer the accessibility question on the next application with evidence instead of a promise — and the WCAG success criteria give you the exact checklist funders and auditors reference.

A common assumption is that nonprofits sit outside ADA litigation. They don’t. Nonprofits open to the public are generally treated as places of public accommodation under Title III, and courts have repeatedly applied Title III to websites — most notably in Robles v. Domino’s Pizza (9th Cir. 2019), where the court held the ADA reached the company’s website and app. Our ADA website compliance overview lays out that baseline in plain terms. (This article is general information, not legal advice; talk to an attorney about your specific exposure.)

The volume is real. UsableNet’s 2024 year-end report counted over 4,000 digital-accessibility lawsuits filed in U.S. courts that year, and plaintiffs frequently target smaller organizations. If your state is a hotspot — see California and New York, which dominate filings, or browse the by-state breakdown — your odds rise further. Many cases begin not with a courtroom but with an ADA demand letter, and the serial plaintiffs behind much of this volume scan for the same predictable barriers.

Skip the overlay; fix the code

It’s tempting for a budget-strapped nonprofit to bolt on an accessibility widget and call it done. We’d steer you away from that. Overlays sit on top of broken markup without repairing it, and UsableNet found that roughly a quarter of 2024’s digital ADA lawsuits named sites that already had an overlay installed — the widget didn’t prevent the suit. We dig into why in do accessibility overlays work?

Curbcut takes the opposite approach: manual remediation of the real HTML, ARIA, and content to WCAG 2.1 AA, starting from an honest audit of where supporters actually get stuck. For a small org, that usually means prioritizing the donate, signup, and program-application paths first — the screens tied to revenue and mission — rather than boiling the ocean. If cost is the worry, our breakdown of what accessibility costs is built around exactly that kind of phased, prioritized work.

You don’t need to guess where you stand. Run a free accessibility scan of your donate page, see the barriers in writing, and decide what to fix first.