Nonprofit Website Accessibility (WCAG & ADA)

Why accessibility is now table-stakes

Roughly one in four U.S. adults lives with a disability, and a large share of those affect how someone uses the web — vision, motor, cognitive, or hearing differences. When your donation form, event registration, or program-eligibility page is unusable with a screen reader or a keyboard, you are turning away supporters and the people you serve. That is the mission case. There is now also a sharp legal case.

The DOJ Title II rule. In 2024 the Department of Justice finalized a rule under ADA Title II that adopts WCAG 2.1 Level AA as the technical standard for the web content and mobile apps of state and local governments (see ADA.gov, "Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps"). In April 2026, DOJ issued an interim final rule extending the original deadlines by one year: entities serving a population of 50,000 or more must comply by April 26, 2027, and smaller entities and special-district governments by April 26, 2028 (as of 2026 — verify, and note DOJ accepted public comments into mid-2026, so dates can still shift).

Title III litigation. Separately, ADA Title III covers "places of public accommodation," and courts have applied it to websites. In 2025, plaintiffs filed about 3,117 website-accessibility lawsuits in federal court — up roughly 27% over 2024 — and an estimated tens of thousands of pre-suit demand letters circulated (as of 2026 — verify; figures come from litigation trackers, not the government). The ADA does not name a technical standard for Title III, but WCAG 2.1 AA is the de facto benchmark courts and plaintiffs use. Crucially, a majority of these suits hit organizations under $25M in revenue, so "we're too small to be a target" is not a safe assumption.

Does the law apply to your nonprofit?

The honest answer is "it depends," and this is the one place to be careful with general guidance. Here is a plain-English map of how the pieces fit together. Treat it as a starting point for a conversation with counsel, not a verdict.

Two practical takeaways. First, WCAG 2.1 AA is the common thread across nearly every pathway, so building to that standard satisfies the substance regardless of which law applies. Second, if you receive government funding, run public-facing programs, or operate a brick-and-mortar location, assume accessibility expectations apply and act accordingly. Your website essentials and broader marketing work should bake this in from the start rather than bolt it on later.

The WCAG basics in plain English

WCAG (Web Content Accessibility Guidelines, from the W3C) is organized around four principles — content must be Perceivable, Operable, Understandable, and Robust ("POUR"). Level AA is the conformance target nearly everyone uses. You do not need to memorize the spec; six categories cover the overwhelming majority of real-world failures. The free W3C WAI WCAG 2.1 Quick Reference lists every success criterion if you want the source of truth.

• Alt text on images. Every meaningful image needs a short text alternative describing its purpose, so screen readers can convey it. Decorative images should have empty alt text (alt="") so they're skipped. Don't write "image of" — just describe what matters.
• Color contrast. Text must contrast enough with its background: at least 4.5:1 for normal text and 3:1 for large text (about 18pt, or 14pt bold) and for meaningful UI components and graphics (as of 2026 — verify against current WCAG). Don't rely on color alone to convey meaning (e.g., red text for "required").
• Keyboard navigation. Everything you can do with a mouse must work with a keyboard alone — Tab to move, Enter/Space to activate. A visible focus indicator must show where you are, and focus must never get trapped.
• Captions and transcripts. Pre-recorded video needs synchronized captions; audio needs a transcript. This also helps the majority who watch social video with sound off.
• Form labels. Every input needs a programmatically associated <label> (not just placeholder text), and errors must be described in text, not signaled by color alone.
• Headings and structure. Use real heading tags (one H1, then H2/H3 nested logically) and lists, links, and landmarks correctly. Screen-reader users navigate by headings, so a clean outline is essential. Link text should make sense out of context ("2026 annual report," not "click here").

How to test for free

You can catch most issues without spending a dollar. Automated tools typically surface only 30-50% of WCAG problems on their own, so combine them with two quick manual checks: tab through the page with your keyboard, and read the W3C's "Easy Checks — A First Review of Web Accessibility."

A sensible free workflow: run Lighthouse for a baseline score, then WAVE on your five highest-traffic pages (home, donate, about, contact, one program page) to see issues visually, then axe DevTools to hand a developer precise violations. Use the Contrast Checker whenever you pick brand colors. Finally, do the human checks no tool can: unplug your mouse and navigate by keyboard, and if you can, run your screen reader (VoiceOver on Mac, NVDA free on Windows) down the donate flow. Refer to ADA.gov's web accessibility guidance for plain-language context on what regulators expect.

Worked example: a small-nonprofit audit

Here's a realistic first audit for "Riverside Youth Mentors," a $400K nonprofit running a WordPress site. A volunteer spent two hours running Lighthouse, WAVE, and a keyboard pass on five key pages, then logged findings in a simple tracker. The numbers are illustrative, not benchmarks.

The volunteer then sorted findings by severity (does it block a task?) and reach (how many users hit it?). The two that blocked the most important task — completing a donation — went to the top: unlabeled donate fields and the keyboard-unreachable Donate button. Contrast and alt-text fixes were quick wins. Captions and the image-only PDF were scheduled for the following week. Total remediation by a volunteer plus the web vendor: about six hours, no budget beyond existing hosting.

A prioritized fix list

Don't try to fix everything at once. Triage by impact on core tasks first (give, register, find help, contact), then frequency, then effort. This order gets you the most protection and the most usable site for the least work.

1. Fix the donate and registration flow first. Label every form field, make every button keyboard-operable with a visible focus state, and ensure errors are described in text. This is where you lose money and where lawsuits concentrate.
2. Repair color contrast on text and buttons. Run brand colors through the WebAIM Contrast Checker and adjust to meet 4.5:1 / 3:1. This is usually a fast CSS change with site-wide benefit.
3. Add alt text to meaningful images; null-out decorative ones. Prioritize images that convey information (charts, infographics, photos with captions-worth content).
4. Clean up heading structure and link text. One H1 per page, logical nesting, and descriptive links. Helps screen-reader users and your SEO at the same time.
5. Caption videos and fix image-only PDFs. Add captions/transcripts; replace scanned-image PDFs with real text (or HTML pages, which are far easier to make accessible).
6. Publish an accessibility statement with a contact method for help, and add accessibility checks to your content workflow so new pages don't reintroduce problems.

Bake the recurring checks into your operations rhythm — for example, a quick WAVE scan before publishing any new landing page, and a full re-audit twice a year. If your site is large, built on a fragile custom platform, or you've already received a demand letter, that's the point to bring in a professional firm (see the resources below).

WCAG quick-audit checklist

Pass on all twelve across your top pages and you've cleared the most common WCAG 2.1 AA failures that drive both poor usability and demand letters. Re-run after every major redesign and at least twice a year.

FAQ