Most charities know their site should work for everyone, but "hire an agency for a full audit" is rarely in the budget. The good news: nonprofit website accessibility is mostly about a handful of pages that do the real work, your donation form, your events listing, and the PDFs you ask people to read. Fix those well and you cover the journeys that matter most to supporters and the people you serve.
This guide skips the abstract compliance lecture and focuses on concrete, low-cost fixes you can make this quarter, ordered by impact. It assumes a small team, no dedicated developer, and a website on a mainstream platform.
Start with the donation form, not the homepage
If one page deserves your first hour, it is the donation form. A supporter who cannot complete it does not just bounce, you lose the gift. Forms are also where accessibility problems cluster, so the return on effort is high.
Work through these in order:
- Labels, not placeholders. Every field needs a visible
<label>tied to its input withfor/id. Grey placeholder text vanishes the moment someone types and is often too low-contrast to read. - Errors that announce themselves. When a donation fails validation, the error must be in text ("Enter a valid card expiry date"), tied to the field, and programmatically associated so a screen reader hears it, not signalled by red colour alone.
- Don't force memory or re-typing. WCAG 2.2's 3.3.7 Redundant Entry (Level A) means if you already collected an address, don't ask for it again unannounced. And 3.3.8 Accessible Authentication (Minimum, AA) means don't block donors with a cognitive puzzle, a CAPTCHA that demands transcribing distorted text can stop a legitimate gift.
- Big enough to tap. The donate button and any preset-amount controls should meet 2.5.8 Target Size (Minimum), 24x24 CSS px, which matters for older supporters on phones.
Many forms are embedded from a third-party processor (Donorbox, JustGiving, a Stripe checkout). You can't always edit those, but you can test them and choose providers that pass. Run a free scan on the page that hosts the form to catch missing labels and contrast issues fast.
Make events findable and bookable for everyone
Event pages are the second pressure point: fundraisers, webinars, volunteer days. Two failures recur on small-charity sites.
First, keyboard access. Date pickers, "add to calendar" widgets, and ticket-quantity steppers are frequently mouse-only. Test by unplugging your mouse: can you Tab to every control, operate it with Enter or Space, and see a clear focus outline as you go? WCAG 2.2 added 2.4.11 Focus Not Obscured (Minimum), so make sure a sticky header or cookie banner never hides the element you've just tabbed to.
Second, information conveyed by layout alone. "Sessions in green are sold out" fails for colour-blind users; add a text label or icon. If your events use a map, give the address and any access details (step-free entrance, hearing loop) in plain text, not just a pin.
Tame your documents, especially PDFs
Nonprofits run on documents: annual reports, grant guidance, impact summaries, consent forms. A scanned PDF is just an image, invisible to a screen reader and unsearchable. This is one of the most common and most overlooked barriers.
Three cheap habits fix most of it:
- Prefer a web page over a PDF. An HTML page is more accessible by default, works on phones, and is easier to update. Reserve PDFs for things that genuinely must be printed.
- If you must use a PDF, make it tagged. Export from Word or Google Docs using real heading styles (Heading 1, Heading 2), add alt text to images, and set the document language. Run the built-in accessibility checker before publishing.
- Never publish a flat scan. Run OCR so the text is selectable, then tag it.
Prioritise by impact, not by checklist length
You will never clear every WCAG criterion at once, and you don't need to. Triage by combining two questions: how many people hit this, and how badly does it block them. A broken donate button on a high-traffic page outranks a missing caption on an archived blog post.
A sensible order for a small team:
- Text contrast. Fixing colours is usually a CSS change and helps everyone in sunlight. Aim for 4.5:1 on normal text and 3:1 on large text (18pt, or 14pt bold) and on UI components like buttons and form borders. Check pairs with a free contrast checker.
- Images and alt text. Decorative images get empty alt (
alt=""); meaningful ones get a short description; a logo gets the organisation's name. - Headings and structure. One
<h1>per page, then a logical<h2>/<h3>outline. Screen reader users navigate by headings, and it helps SEO too. - Keyboard and focus, then forms, as covered above.
Run a free automated scan first to find the obvious wins, then sanity-check the rest by hand with the accessibility checklist. Automated tools catch only part of the picture, roughly a third to half of issues, so the keyboard and screen reader spot checks above are what catch much of the rest.
Where the law sits, briefly
Many charities aren't legally bound to a specific standard the way large companies are, but the bar is converging on one place: WCAG 2.2 Level AA. The European Accessibility Act (Directive (EU) 2019/882), which applies from 28 June 2025, uses WCAG 2.2 A and AA via EN 301 549 as its baseline. If your nonprofit acts as an economic operator, selling event tickets, memberships, or merchandise to consumers in the EU, that scope can reach you.
Even where no statute applies, WCAG 2.2 AA is the practical target funders and partners expect. Treat the WCAG standard as your reference, publish a short, honest accessibility statement describing where you are and how to report problems, and you've covered both the spirit and most of the letter.