All industries » Nonprofit website accessibility
Nonprofit website accessibility: Section 504, Title III, donate forms, 990s
Nonprofit websites are subject to ADA Title III as commercial public accommodations whenever the organization has a physical office, program site, or service location that members of the public visit. Nonprofits receiving federal financial assistance (most 501(c)(3)s that take any federal grant, contract, or pass-through funding from HHS, HUD, DOJ, DOE, or the IRS Volunteer Income Tax Assistance program) are also covered by Section 504 of the Rehabilitation Act. The HHS May 2024 final rule on Section 504 explicitly adopts WCAG 2.1 Level AA as the standard for covered-entity web content and mobile apps. Site Brace audits any nonprofit website for $149 flat.
Short answer: the highest-risk surface on a nonprofit site is the donate form. An inaccessible donate flow blocks a screen-reader-using donor from giving money the organization needs, which is both a compliance failure and a revenue failure. After the donate form, the next priorities are volunteer signup, event registration, downloadable 990s and annual reports, and program-detail pages with photo-heavy beneficiary stories. Site Brace audits up to 25 pages for $149 flat. Try a free single-page check on your donate page first.
The rules that apply to nonprofits
1. ADA Title III (when you have a physical location open to the public)
ADA Title III applies to any commercial public accommodation that members of the public visit. For nonprofits, that includes program sites, food pantries, shelters, community centers, museums, libraries operated by 501(c)(3)s, after-school programs, and any office where the public comes for services. Purely virtual nonprofits (no physical presence) have a weaker Title III nexus but still face exposure under the digital-only theory that several federal courts have accepted since 2019.
2. Section 504 of the Rehabilitation Act (if you receive federal funding)
Section 504 prohibits disability-based discrimination by entities receiving federal financial assistance. The May 2024 HHS final rule made the standard explicit: WCAG 2.1 Level AA for web content and mobile apps. Most 501(c)(3) nonprofits take some federal funding, even if indirectly through state pass-through grants. If your audit, your 990, or your board minutes show federal grant revenue, Section 504 applies. The compliance deadline is May 2026 for recipients of $2.5 million or more in federal funds; May 2027 for smaller recipients.
3. Section 1557 (if you do anything health-related)
Community health centers, free clinics, recovery programs, and behavioral health nonprofits often fall under Section 1557 if they accept Medicaid, Medicare, or any HHS funding. The Section 1557 May 2024 rule mirrors the Section 504 standard: WCAG 2.1 Level AA. See the healthcare website ADA guide for the full Section 1557 framework.
4. State laws and state Attorney General enforcement
State human-rights and accessibility statutes apply to nonprofits the same as to any other entity. State Attorneys General have brought several enforcement actions against nonprofits in the last five years, usually triggered by a complaint from a donor or beneficiary who could not use the site. The Massachusetts AG action against a regional United Way affiliate in 2022 is the often-cited example.
The high-risk surfaces specific to nonprofit sites
The donate form
The donate form is the highest-stakes accessibility surface a nonprofit has. Most nonprofits use a third-party donation platform: Classy, Donorbox, GiveButter, Network for Good, Bonterra (formerly Bloomerang), Salsa, Kindful, or a Stripe-hosted custom flow. Each platform has its own accessibility baseline; the embedded widget often inherits the host site's styles in ways that break contrast or focus rings that worked in the vendor's preview. The donate form is the one surface where a single accessibility bug directly costs the organization revenue every time it blocks a donor.
Volunteer signup and event registration
Volunteer signup forms ask for the same field set as a donate form (name, email, sometimes a waiver checkbox) but with less attention to form quality because the conversion is lower-stakes. Event registration forms add date pickers and quantity selectors that frequently fail keyboard accessibility. Both surfaces are direct conversion paths that an inaccessible field blocks.
Downloadable 990s, annual reports, and impact documents
The IRS Form 990 (publicly filed annually) is required to be available on request. Most nonprofits post it on the website along with an annual report and impact summary. These are usually PDFs exported from InDesign or Canva without accessibility tagging. A screen-reader user cannot navigate an untagged PDF; a donor or grantor evaluating the organization cannot get to the information they need.
Beneficiary stories and program pages
Nonprofit program pages lean on photography of program participants and beneficiaries. Alt text on those photos has two requirements at once: it must describe the image for screen readers, and it must do so in a way that respects the dignity of the people pictured. Generic alt text like "smiling child" both fails accessibility and reduces the people pictured to a category.
What we typically find on a nonprofit website
| Finding | axe-core rule | Typical cause |
|---|---|---|
| Donate form fields rely on placeholder text instead of labels | label |
Classy, Donorbox, or GiveButter widget with default styling, or custom Stripe form built without labels |
| Donate amount preset buttons have insufficient contrast on hover state | color-contrast |
Hover state uses a lighter brand color than the resting state, dropping below 3:1 |
| 990 or annual report PDF is not tagged for screen readers | Manual finding (PDF interior) | Exported from InDesign or Canva without tagging; or scanned image-only PDF |
| Beneficiary photos have empty or generic alt text | image-alt |
CMS auto-populates from filename, or alt left blank |
| Event registration date picker is not keyboard-operable | Manual finding | Older jQuery datepicker library or unmaintained custom calendar widget |
| Newsletter signup form in the footer has no label | label |
Mailchimp or Constant Contact embed code styled with placeholder-only labels |
| aria-label on generic header or section element | aria-prohibited-attr |
WordPress theme or accessibility-overlay injection. See aria-label on a div. |
| "Donate" sticky bar covers the keyboard-focused element behind it | Manual finding | Fixed-position sticky CTA without scroll-padding adjustment for keyboard focus |
Notes on common nonprofit platforms
WordPress with GiveWP or Donorbox embed
The most common stack for small to mid-size nonprofits. Theme accessibility varies widely; older themes have more debt. The donate plugin or embed has its own accessibility baseline that is sometimes better than the host theme and sometimes worse.
Squarespace
Common for arts, cultural, and small-program nonprofits. Squarespace native forms have improved on label handling in the last two years but still ship templates with sub-4.5:1 contrast on light-on-light brand variations. The donate flow usually goes through a third-party widget embedded in a Squarespace code block.
Classy or Network for Good as the primary site
Some nonprofits run the entire site on Classy or a Network for Good Microsite rather than embed-and-host. Platform-level accessibility issues affect every nonprofit on the platform simultaneously; remediation depends on the vendor's roadmap.
Why overlays are a poor fit for nonprofits
Accessibility overlays are heavily marketed to nonprofits as a low-cost compliance fix. We have written about why accessibility overlays do not make sites WCAG-compliant in detail. For nonprofits specifically:
- Overlays do not enter embedded donation widgets running in iframes. The donate form, the single most important surface on the site, is the surface overlays never reach.
- Overlays do not fix downloadable PDFs. The 990, the annual report, the impact document all stay inaccessible.
- Federal grant audits and Section 504 substantiation requests cite WCAG conformance evidence, not overlay subscriptions. HHS and DOJ have explicitly stated overlays are not a defense.
- The FTC's $1 million settlement with accessiBe in April 2025 makes overlay compliance claims a documented liability, which board members and major donors increasingly know about.
How Site Brace audits a nonprofit website
The standard page mix for a nonprofit audit:
- Homepage
- Donate page (and the next 2-3 steps of the donate flow if the form is multi-step)
- Program or services pages (top 3-5)
- Impact or "Our work" page
- Volunteer signup page
- Events or calendar page (and 1 event-detail page)
- About us, board, and staff pages
- Financial transparency page (where the 990 lives) plus the most recent 990 PDF
- Annual report landing page plus the most recent annual report PDF
- Newsletter signup or email subscribe page (if separate)
- Contact us
- Accessibility statement (if one exists)
That mix covers up to 25 pages for a typical nonprofit website. The audit runs axe-core 4.10 against each page, captures element-level screenshots of every contrast failure, opens the linked PDFs and notes their tagging state, and packages the findings into a written report with copy-paste fix code and 12 re-scans included over 12 months.
Pricing is $149 flat, one-time. To see what the report looks like, view a sample report we built for a fictional municipality. The nonprofit findings are similar in shape (forms, photos, PDFs, headers) even though the regulatory framing is different. For nonprofits writing grant proposals or board reports about accessibility work, the per-criterion WCAG evidence the audit produces is the substantiation grant reviewers and boards ask for.
Want to check your own site first? Run a free single-page check on your donate page or your homepage - one URL, about a minute, no signup needed to see the result.
Start a nonprofit website audit, $149
Related:
- Healthcare website ADA compliance - for nonprofits running clinics, recovery programs, or behavioral health programs covered by Section 1557
- Free single-page WCAG check
- Why accessibility overlays do not make sites WCAG-compliant
- axe-core vs WAVE vs Lighthouse
- aria-label on a div: why screen readers ignore it