How many fields should a nonprofit donation form have?

As few as possible. The core fields are donation amount, payment details, email address and an option to make it recurring. Gift Aid (for UK charities) adds a declaration and the donor's full name and home address, which HMRC requires . Anything more needs a specific justification, because every extra field reduces completion rates.

Should we use our website platform's built-in forms or a third-party tool?

It depends on what the form needs to do. For simple contact and enquiry forms, built-in form tools are usually enough. For donations, a dedicated payment platform you embed (Fundraise Up, Donorbox or similar) is almost always better, because it handles payment processing, receipting and compliance. For complex registration forms, Jotform or Typeform may offer better conditional logic. Whatever you choose, the form must be accessible and the data handled in line with your data protection obligations .

How do I know if our forms are accessible?

Test them. Complete every form on your site by keyboard alone, listen to it with a screen reader (VoiceOver on Mac, NVDA on Windows), and run the axe DevTools browser extension on every page with a form. If any field is unlabelled, any error message is unclear, or any step needs a mouse, the form fails WCAG 2.2 (at Level A, not merely AA) and needs fixing.

Form Design for Nonprofit Websites

Key takeaways

Forms are the point where a visitor's intention becomes action, and every friction point silently turns intent into abandonment that never gets reported.
Donation, contact, and volunteer or event registration forms carry the most institutional weight, affecting revenue, relationships, and operational quality respectively.
Ask only for the fields you genuinely need, since every unnecessary field reduces completion, and "our CRM needs it" is not a strong enough reason if it costs donors.
Common accessibility failures include unlabelled fields, where placeholder text is no substitute for a label, and error messages that rely on colour alone or omit which field is wrong.
Every form must be completable by keyboard, with a logical tab order and a reachable submit button, and embedded payment widgets are prone to keyboard traps.
Confirm submission unambiguously and test forms by actually completing them on a mobile device, because phones carry most nonprofit traffic and convert worst.

Summary

Nonprofit website forms (contact forms, volunteer enquiry forms, newsletter sign-ups, service referral forms, and donation forms) are the points at which a visitor's intention becomes an action. Every friction point in a form is a place where intention does not become action: a donor who abandons the donation form partway through, a volunteer who cannot complete the application because a required field is unlabelled, a beneficiary who cannot submit a referral because the form times out on their phone's slow connection. Form design failures on nonprofit websites are rarely dramatic. They are small, accumulated barriers: a required field that is not clearly marked as required, an error message that says invalid input without explaining what valid input looks like, a form that does not work on mobile, a confirmation message that provides no information about what happens next. None of these barriers stop everyone. All of them stop some people, and for a nonprofit whose primary audiences include beneficiaries with limited digital literacy, older donors using assistive technology, and volunteers using mobile devices, those stopped people include exactly the groups the organisation most needs to be accessible to. This post covers form design governance for nonprofit websites: the accessibility requirements for forms under WCAG 2.2, the specific design patterns that reduce abandonment for different form types, how to test form functionality across devices and network conditions your actual users are likely to use, how to route form submissions appropriately so data reaches the right team without passing through unsecured email, and how to include form performance in the website governance monitoring schedule so that failures are caught and addressed rather than accumulating unnoticed.

Every nonprofit website has forms, and each one is a moment where a visitor has decided to act. Poor design silently turns that intent into abandonment.

The forms include:

contact forms;
donation forms;
volunteer sign-ups;
event registrations;
newsletter subscriptions;
grant enquiries.

You never see abandonment. A visitor who leaves because the form was too long, confusing or inaccessible does not write to explain. Your analytics may show a high bounce rate, but not that the form asked for a phone number they did not want to give, or that the submit button was invisible to their screen reader.

The scale is well documented. According to Zuko Analytics' benchmarking data, only 45% of people who visit a form convert successfully. A 2018 survey by The Manifest found that 81% had recently abandoned at least one online form, and that most of them did not go back to finish it.

Form design is not a detail. On nonprofit websites, it is how institutional relationships begin.

The forms that matter most

Three form types deserve particular attention, because they directly affect revenue, relationships and compliance.

Donation forms

The donation form is the most consequential. Every unnecessary field, confusing step or accessibility failure loses someone who wanted to give.

If your form asks for more than name, email, payment details and amount, you need a strong reason for each extra field. "Our CRM needs it" is not a strong reason if it costs you donors.

The form must work flawlessly on mobile, because mobile is where it converts worst. M+R Benchmarks 2026 found that 11% of desktop users who landed on a primary donation page completed a gift, against 8% of mobile users. Mobile accounted for 52% of all traffic but only 43% of donation transactions and 28% of revenue.

Most of the study's participants are US nonprofits, so read it as US-weighted: a direction, not a UK figure. The direction is still the one to design for. Test the donation form on a phone before anywhere else, for the same reason heading sizes belong to the phone first.

Contact and enquiry forms

This is how institutional relationships begin. When a funder, partner or journalist reaches out, the form shapes their first impression of your competence:

Does it ask relevant questions?
Does it confirm submission clearly?
Does the enquiry actually reach someone who responds?

Picture a contact form that submits to an email address nobody monitors. Every enquiry disappears.

Volunteer and event registration forms

These are where operational quality becomes visible. They often ask for the most information: availability, skills, DBS status, dietary requirements, accessibility needs.

They are also the most likely to be built in a hurry, by someone who is not a designer, with whatever tool was available. The result is often a form that works for the person who built it and fails for the people who need it.

The accessibility failures nobody checks

Form accessibility is one of the most common WCAG failures on nonprofit websites, and one of the least likely to be caught without deliberate testing. Most of the failures below sit at Level A, the floor of the standard, not AA.

Unlabelled fields

Every input needs a programmatically associated label, so screen readers can announce what is being asked. Placeholder text is not a label: it disappears when the user starts typing.

This is not an edge case. It fails 3.3.2 Labels or Instructions and 4.1.2 Name, Role, Value, both Level A, and it affects anyone using assistive technology.

Error handling

Error messages must be specific, visible and tied to the relevant field. Two common patterns fail:

"Please correct the errors below" without saying which fields.
Changing a field's border colour with no text, because colour alone is not a sufficient indicator under WCAG.

Two criteria apply, at two levels. 3.3.1 Error Identification (Level A) requires that the field in error is identified and the error described in text. 3.3.3 Error Suggestion (Level AA) requires that you also offer a correction when you know one.

Every form must be completable by keyboard alone: that is 2.1.1 Keyboard, Level A. The tab order must be logical, focus indicators visible and the submit button reachable.

Donation forms that embed a third-party payment widget are particularly prone to keyboard traps, where a user tabs into the widget and cannot tab out.

These failures decide whether a donor with a visual impairment can give, whether a volunteer using voice control can sign up, and whether your site meets the legal accessibility standards that apply to your sector.

What good form design looks like

A few principles apply whatever the form type.

Ask only for what you need. For a donation, that is payment details and an email for the receipt. Not a phone number, postal address or reason for giving, unless you have a specific, justified use for each, such as a home address for a Gift Aid declaration. For every field, ask: if we removed this, what would we lose? If the answer is "nothing meaningful," remove it.
Label every field clearly. The label sits above the field, stays visible while it is active, and says exactly what is expected. "Name" is ambiguous; "Full name" is clear. "Email" is fine; "Please enter your preferred contact email address" is unnecessary.
Write useful error messages. "This field is required" is minimally helpful. "Please enter your email address" is better. "Please enter a valid email address (example: name@organisation.org)" is best. Put the error next to its field, not in a summary at the top of the page.
Confirm submission clearly. Use a success message on the same page, a redirect to a thank-you page, or a confirmation email. Silence creates anxiety, and anxious users submit again, creating duplicates.
Test on mobile. Do not just check the form renders on a phone: complete it. Fill in every field, submit, check the confirmation, and fix anything awkward before launch. On the M+R figures above, phones carry over half of nonprofit traffic and under half of donation transactions.

The governance question behind form design

Form design decisions are governance decisions:

What you collect sets your data protection obligations. Any form that gathers personal data needs a lawful basis under Article 6 of the UK GDPR, and the person filling it in must be given the privacy information set out in Article 13 at the point of collection. Consent is only one of the lawful bases, and it is rarely the right one for a contact form.
How accessible your forms are determines whether you meet legal accessibility requirements.
Where submissions are routed determines whether enquiries reach the right person or disappear into an unmonitored inbox.

Referral forms

Referral forms raise the stakes. A form that asks about someone's health collects special category data, which the ICO says needs a separate Article 9 condition as well as the Article 6 basis. The consent wording follows whichever condition your data protection lead relies on.

What a referral form must tell people, including when a professional refers someone else, is in service pages for people in crisis.

The part most often missed is where the submission lands:

The form provider stores it, as a processor you need a contract with under Article 28.
The notification email copies the answers into an inbox, which may be shared and synced to several phones.
Article 32 requires security appropriate to the risk, and every copy is another place the risk sits.

I would have the notification say only that a referral has arrived, and keep the answers in one place with access limited to the people who act on them. The referral forms row of the section checklist and the GDPR checklist carry the rest.

Five questions for every form

The Communications Director should be able to answer these for every form on the site:

Where do submissions go?
Who monitors them?
What data is collected?
How long is it retained?
Is the form accessible?

If any answer is "I do not know," that is a governance gap with real consequences.

These sit under different law again. Marketing email is governed by regulation 22 of PECR rather than by the UK GDPR alone.

Since 5 February 2026, the charity soft opt-in at section 114 of the Data (Use and Access) Act 2025 has let a charity email people who gave their details while expressing an interest in its purposes. What that requires of the form is not a consent tick-box: it is a free and simple way to refuse at the point of collection, and another in every message that follows.

If you are not confident that your website's forms are accessible, properly routed, and serving your primary stakeholders effectively, a Blueprint Audit tests every form on your site and identifies the specific failures that are costing you donors, volunteers, and institutional relationships.

About Socialectric

Works with

Credentials

Reviewed on

Form Design for Nonprofit Websites: Accessibility, Conversion, and Trust