WCAG compliance for nonprofit websites means meeting the Web Content Accessibility Guidelines at Level AA, the benchmark that US accessibility rules, federal grant conditions, and most institutional funders now point to. Build to WCAG 2.2 Level AA and you cover the 2.1 Level AA that current federal rules name.
That’s the answer. The harder question is where to start, because most nonprofit sites fail in the same handful of places, and most teams fix them in the wrong order.
The practical cost usually lands long before any legal one. An inaccessible donation form doesn’t only expose you to a complaint. It turns away the supporter who was ready to give, on the one screen where you can’t afford to lose anyone.
This guide covers which laws reach a nonprofit, the six failures behind most errors, how to audit your site, and what to fix first. You’ll leave with a sequence you can hand to your board or your developer.
Key Takeaways
- Build to WCAG 2.2 Level AA. It adds to WCAG 2.1 rather than replacing it, so you cover the 2.1 Level AA standard that current US federal rules name.
- There is no single nonprofit web accessibility law. Most organizations are reached through ADA Title III as a place of public accommodation, through Section 504 if they take federal funding, or through a government contract.
- Six failure types account for 96% of all errors detected across the top one million home pages, and low contrast text alone appears on 83.9% of them.
- A clean automated scan is not conformance. WebAIM counts only the failures a machine can find, so the keyboard pass and a screen reader run on your donation flow matter more.
- Fix the donation and registration flows before the homepage, and move the rules into your design system so new pages stop reintroducing the same six errors.
What WCAG compliance means for a nonprofit website
Compliance is a floor, not the point. The point is that someone using a screen reader, a keyboard, or a phone in bright sunlight can do the thing they came to do: give, register, apply, find out whether your program is for them.
The Web Content Accessibility Guidelines are the W3C standard behind that idea. They organize under four principles (content should be perceivable, operable, understandable, and robust) and come in three conformance levels: A, AA, and AAA.
Level AA is the working target. It’s what regulators cite, what funders ask about, and what courts have used as a yardstick. Level AAA isn’t the goal, and chasing it is a reliable way to spend a year and ship nothing, since some AAA criteria can’t be met for certain kinds of content.
On versions: WCAG 2.1 (2018) is what current US federal rules name, WCAG 2.2 (October 2023) is the current recommendation, and 2.2 adds to 2.1 rather than rewriting it. WCAG 3.0 is still a working draft with years to go, so don’t wait for it. Build to 2.2 AA and you’ve covered both.
Which accessibility laws apply to nonprofits
Most teams get stuck here, because they go looking for a nonprofit accessibility law and find no such single thing exists. There are three doors instead, and a mid-sized organization is often standing in more than one.
- ADA Title III. Most 501(c)(3) organizations open to the public are places of public accommodation. The Department of Justice has not issued a technical web standard for Title III, which is why WCAG Level AA has become the practical benchmark in complaints and settlements.
- Section 504 of the Rehabilitation Act. If you receive federal financial assistance, this reaches you. The Department of Health and Human Services adopted WCAG 2.1 Level AA for its recipients, and in May 2026 extended the compliance dates to May 11, 2027 for recipients with 15 or more employees and May 10, 2028 for smaller ones.
- ADA Title II, by association. If you deliver services under contract for a state, county, or city, their obligations can flow to you through the agreement. The DOJ likewise pushed those dates back to April 26, 2027 for entities serving 50,000 or more people, and April 26, 2028 for smaller entities and special districts.
Two caveats. None of this is legal advice, and which door applies depends on your programs and funding, so ask your counsel rather than a blog post. And those extensions are a scheduling change, not a reprieve: the standard didn’t move, and the obligation to serve disabled people never depended on a deadline.
In our nonprofit brand and product work, the trigger is almost never a lawsuit. It’s a question on a grant application, or a funder’s procurement review, landing three weeks before the submission is due.
Start with the six failures behind most WCAG errors
The good news buried in the data is that accessibility failures are repetitive. According to WebAIM’s 2026 Million report, 95.9% of the top one million home pages had detectable WCAG 2 failures, averaging 56.1 errors per page. Both numbers got worse year over year, up from 94.8% and 51 errors.
Six error types accounted for 96% of everything found:
- Low contrast text, on 83.9% of pages. The pale gray caption under your impact number.
- Missing image alt text, on 53.1%. The program photos and the infographic that carries the statistic.
- Missing form input labels, on 51%. The unlabeled amount field and the placeholder-only email input on your donation form.
- Empty links, on 46.3%. Icon-only social links in the footer, announced to a screen reader as nothing at all.
- Empty buttons, on 30.6%. The arrow-only control on your event carousel.
- Missing document language, on 13.5%. One attribute in your page template.
Not one of those needs a redesign to fix. They’re attributes, labels, and color values, most of which live in a handful of shared components. This is the cheapest work in accessibility, and it’s where a small team should spend its first two weeks.
How to audit a nonprofit website for WCAG compliance
Run the passes in this order, because each one finds something the previous one can’t.
- Automated scan. Use axe DevTools, WAVE, or Lighthouse across 10 to 15 representative templates, not every page. You’re sampling the system, not counting URLs.
- The keyboard pass. Put the mouse away and Tab through your donation flow. Can you reach every control? Can you see where you are? Can you escape the newsletter modal? This single exercise finds most of what genuinely blocks people.
- A screen reader on the flows that matter. VoiceOver ships on Mac, and NVDA is free on Windows. Run the donate and sign-up paths end to end, including the confirmation screen and the receipt email.
- Real users, paid for their time. Nothing in the first three steps tells you whether your eligibility page makes sense to the person who needs the program.
Don’t treat a clean scan as a clean bill of health. WebAIM counts only the failures a machine can detect, so full conformance is rarer than even those numbers suggest. Scanners are good at volume. A person with a keyboard finds what stops someone cold.
One shortcut is worth refusing. If a vendor offers one line of JavaScript that makes you compliant, be skeptical. An overlay can’t label a form field that has no label in your codebase, and hundreds of accessibility practitioners have signed an open fact sheet documenting the problems overlays cause for the people they claim to help.
Fix the donation and sign-up flows first
Prioritize by journey, not by page count. The homepage gets the audit attention because it’s first in the crawl. The donation form is where the consequence lands.
We’d sequence it this way:
- The donation or registration flow, end to end.
- Primary navigation and search, since everything downstream depends on getting there.
- Program and eligibility pages, where someone decides whether your service is for them.
- PDFs that carry real information, starting with the annual report nobody tagged.
- Everything else, on a normal content cadence.
The reasoning is the same one behind our human-centered design practice: design for the person on the other side of the screen, doing a real task. A first-time donor on their phone at 11pm has one job. Every barrier between them and finishing it costs you the gift and costs them the chance to act.
When we did product-led growth for Kiva, the lending flow was the product, and every step someone couldn’t complete was a loan that didn’t get funded. Your donate button works the same way.
Make accessibility part of the system, not the backlog
Here’s the failure mode we see most: an organization runs a remediation sprint, fixes 300 errors, and is back to 200 within a year. Nothing regressed on purpose. The site simply kept growing, and every new landing page reintroduced the same six problems.
So put the rules where the work happens:
- Contrast values in the design tokens, so a failing color isn’t available to pick in the first place.
- Labels, focus states, and required alt text baked into the component library, so the accessible version is the default version.
- A keyboard check in the definition of done, alongside the browser testing you already do.
- A required alt text field in the CMS, and a named person accountable for what goes in it.
- One owner, even at a tenth of their time. Shared ownership of accessibility reliably means none.
This is also where the honest trade-off sits. You probably don’t need a redesign. If your site is a few years old and structurally sound, component-level remediation beats a rebuild on both cost and speed, and you should push back on anyone who quotes you a redesign to solve a contrast problem. A rebuild earns its cost only when the templates themselves generate the errors, which is a real conversation about engineering and re-platforming, not an accessibility line item.
Frequently asked questions
Is WCAG compliance legally required for nonprofits?
Usually yes, though indirectly. No US law says “nonprofits must meet WCAG,” but most 501(c)(3) organizations are covered by ADA Title III as places of public accommodation, and any organization taking federal financial assistance is covered by Section 504, where WCAG 2.1 Level AA has been named explicitly. WCAG Level AA is the standard regulators, courts, and funders use in practice.
How much does it cost to make a nonprofit website accessible?
It depends almost entirely on how much of your site is built from shared components. If your templates are consistent, fixing the six most common failures is days of developer time, not a capital project. Costs climb when the problems are structural: custom widgets without keyboard support, an inaccessible third-party donation platform, hundreds of untagged PDFs. Get the audit before you get the estimate.
Do accessibility overlay widgets make a website WCAG compliant?
No. Overlays adjust some surface presentation, but they can’t repair missing labels, bad heading structure, or keyboard traps in your code, and organizations using them have still faced complaints. Spend the subscription on fixing the source.
Does accessibility work help SEO?
Yes, as a side benefit rather than a reason. Descriptive alt text, real heading hierarchy, labeled form fields, and meaningful link text are the same signals search crawlers and AI assistants use to read a page. Accessible markup tends to be legible markup. Do it for the person using the screen reader and take the ranking upside as a bonus.
Where to start on WCAG compliance
WCAG compliance for nonprofit websites is less daunting than the acronyms suggest. Build to WCAG 2.2 Level AA. Work out which doors apply to you, and note the 2027 and 2028 deadlines now. Fix the six common failures in your shared components. Audit your donation flow with a keyboard and a screen reader, not a scanner alone. Then move the rules into your design system so the next page starts accessible.
The sequence matters more than the speed. An organization that fixes its donation flow and its component library this quarter is in better shape than one that spends the year producing an accessibility statement.
If you want a partner who treats access as part of the craft rather than a compliance line item, start a conversation with Niftic. We bring brand, design, and engineering to the same table, so the accessible version is the one that ships.