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

Every nonprofit website has forms. Contact forms. Donation forms. Volunteer sign-up forms. Event registration forms. Newsletter subscription forms. Grant enquiry forms. Each one represents a moment where a visitor has decided to act, to give their time, money, or attention to your organisation. And each one is a point where poor design silently turns that intent into abandonment.

The problem with form abandonment is that you never see it. A visitor who leaves your donation page because the form was too long, confusing, or inaccessible does not send you a message explaining why. They just leave. Your analytics might show a high bounce rate on the page, but it will not tell you that the form asked for a phone number they did not want to give, or that the error messages were incomprehensible, or that the submit button was invisible to their screen reader. The scale of this problem is well documented. According to Zuko Analytics' benchmarking data, only 45% of people who visit a page with a form go on to complete it. Research by The Manifest found that 81% of people have abandoned at least one web form. For nonprofits specifically, industry data puts the average donation page conversion rate at just 17%, meaning roughly eight out of ten donors who arrive at your donation form ready to give will leave without completing their gift.

Form design is not a detail. On nonprofit websites, it is the mechanism through which institutional relationships begin.

The forms that matter most

Not every form on a nonprofit website carries the same institutional weight. Three form types deserve particular attention because they directly affect revenue, relationships, and compliance.

The donation form is the most consequential. Every unnecessary field reduces completion rates. Every confusing step loses a potential donor. Every accessibility failure excludes someone who wanted to give. If your donation form requires more than name, email, payment details, and amount, you should have a strong reason for each additional field. "Our CRM needs it" is not a strong reason if it costs you donors. The form should work flawlessly on mobile, because most first-time donors will encounter it on a phone. The M+R Benchmarks study (2025) found that nonprofit donation forms convert at 11% on desktop but just 8% on mobile. That gap alone represents significant lost revenue for organisations that have not optimised their mobile donation experience.

The contact or enquiry form is how institutional relationships begin. When a funder, partner, or journalist reaches out through your website, their first impression of your organisation's competence is shaped by the form itself. Does it ask relevant questions? Does it confirm submission clearly? Does the enquiry actually reach someone who responds? I have audited nonprofit websites where the contact form submitted to an email address that nobody monitored. Every enquiry disappeared.

Volunteer and event registration forms are where operational quality becomes visible. These forms 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, using whatever form tool was available. The result is frequently a form that works for the person who built it and fails for the people who need to use it.

The accessibility failures nobody checks

Form accessibility is one of the most common WCAG AA failures on nonprofit websites, and one of the least likely to be caught without deliberate testing.

The most basic failure is unlabelled form fields. Every input field must have a programmatically associated label so that screen readers can announce what information is being requested. Placeholder text inside the field is not a label. It disappears when the user starts typing, leaving them with no indication of what they were supposed to enter. This is not an edge case. It is a fundamental accessibility failure that affects anyone using assistive technology.

Error handling is the second common failure. When a user submits a form with missing or invalid information, the error messages must be specific, visible, and associated with the relevant field. "Please correct the errors below" without indicating which fields have errors is not accessible. Neither is changing the border colour of the problematic field without any text explanation, because colour alone is not a sufficient indicator under WCAG.

Keyboard navigation is the third. Every form must be completable using a keyboard alone, without a mouse. This means the tab order must be logical, focus indicators must be visible, and the submit button must be 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 are not theoretical concerns. They determine whether a donor with a visual impairment can give to your organisation, 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

Good form design for nonprofit websites follows a small number of principles that apply regardless of the specific form type.

Ask only for what you need. Every field that does not directly serve the purpose of the form is friction. If the purpose is a donation, you need payment details and an email for the receipt. You do not need a phone number, a postal address, or an explanation of why they are donating, unless you have a specific, justified use for each of those fields. Review every form on your site and ask: if we removed this field, what would we lose? If the answer is "nothing meaningful," remove it.

Label every field clearly. The label should appear above the field, remain visible when the field is active, and describe exactly what is expected. "Name" is ambiguous. "Full name" is clear. "Email" is fine. "Please enter your preferred contact email address" is unnecessary. Clarity without clutter.

Provide 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. The error should appear next to the field it refers to, not in a summary at the top of the page that the user has to scroll back up to find.

Confirm submission clearly. After a user submits a form, they need immediate, unambiguous confirmation that it worked. A success message on the same page, a redirect to a thank-you page, or a confirmation email. Silence after submission creates anxiety, and anxious users submit the form again, creating duplicate entries and confusion.

Test on mobile. Not "check that the form renders on a phone screen," but actually complete the form on a mobile device. Fill in every field. Submit it. Check the confirmation. If any step is awkward, unclear, or broken, fix it before launch. Most form completions on nonprofit websites happen on mobile devices.

The governance question behind form design

Form design decisions are governance decisions. How much information you collect affects data protection obligations under GDPR. How accessible your forms are determines whether you meet legal accessibility requirements. Where form submissions are routed determines whether enquiries reach the right person or disappear into an unmonitored inbox.

The Communications Director should know the answers to these questions for every form on the site: where do submissions go, who monitors them, what data is collected, how long is it retained, and is the form accessible? If the answer to any of those is "I do not know," that is a governance gap with real consequences.

Question 1: 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 eligibility (for UK charities) adds one field. Anything beyond that should have a specific justification. Every additional field reduces completion rates. The goal is to make giving as easy as the donor's intent demands.

Question 2: 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 sufficient. For donation forms, a dedicated payment platform (Fundraise Up, Donorbox, or similar) is almost always better because it handles payment processing, receipting, and compliance. For complex registration forms, a tool like Jotform or Typeform may offer better conditional logic. Whatever you choose, the form must be accessible and the data must be handled in accordance with your data protection obligations.

Question 3: How do I know if our forms are accessible?

Test them. Use keyboard-only navigation to complete every form on your site. Use a screen reader (VoiceOver on Mac, NVDA on Windows) to hear how the form is announced. 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 cannot be completed without a mouse, the form fails WCAG AA and needs to be fixed.

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.