How to Make Nonprofit Donation Forms More Accessible

A donor has chosen an amount, entered their details, and is ready to complete the donation. Once they reach this point the form presents an error they can't identify, a button they can't reach with a keyboard, or a payment step their screen reader can't understand. This is where their decision to donate will most likely end.

This is one of the main reasons why donation forms deserve particular attention in a nonprofit's accessibility work.

Our broader nonprofit accessibility guide, which covers the ADA, Section 504, and WCAG in full, introduces donation forms as one of several high-impact areas. This article goes further: the specific patterns that break donation forms for keyboard and screen reader users, how to handle errors and multi-step flows correctly, and what to check when a third-party platform handles the actual payment.

Why donation forms deserve extra attention

Most pages on a nonprofit website are read. A donation form has to be completed: fields filled in correctly, an amount chosen or entered, an error understood and fixed, and a transaction confirmed, often within a limited number of steps. Every one of those moments is a place where an inaccessible pattern can stop someone before they finish.

WCAG reflects this. Most of its form-related success criteria apply broadly, but one, Error Prevention, applies specifically to steps that create a legal commitment or a financial transaction, which describes a donation form directly.

What this looks like for a donor: one form, two experiences

Maya is blind and uses a screen reader with Chrome. She's responding to an email appeal from a food bank and wants to set up a $50 monthly gift.

On a form with common accessibility issues

1. She presses Tab and lands on the preset amounts. Her screen reader says "button, button, button, button." The dollar figures are styled text inside unlabeled containers, so she can't tell which one is $50.
2. She tabs to the next field and hears "edit, blank." The placeholder reads "Email address," but placeholders aren't reliably announced, and there's no label behind it.
3. She finds a checkbox, toggles it, and hears nothing about its state or what it does. She doesn't know whether her gift is now monthly.
4. She submits. Two fields outline in red at the top of the page, but focus stays on the submit button, and nothing is announced. As far as her screen reader is concerned, nothing happened.
5. She tabs back through, looking for the problem, and finds "Invalid entry" beside one field. It doesn't say what's invalid or what to enter instead.
6. She leaves. The organization logs an abandoned donation, not an accessibility barrier.

On the same form, built accessibly

1. Focus moves into a group announced as a set: "Choose an amount, $50, 2 of 5, selected." She knows the options and where she is among them.
2. Each field announces its own label: "Email address, edit, required."
3. The recurring option announces "Make this a monthly gift, checkbox, checked."
4. On submit, focus moves to an error summary that announces how many errors there are and links to each one.
5. Each message explains the fix: "Enter your card's 3-digit security code, found on the back of the card."
6. Before the charge, a review step shows the amount, frequency, and payment method, with a way to go back and change them, satisfying WCAG's Error Prevention criterion for financial transactions.
7. She completes the donation in roughly the same time as anyone else.

The second form isn't harder to build. The difference is labels, announced states, deliberate focus handling, and error messages that say what to do.

Common accessibility barriers on donation forms

These patterns show up repeatedly on nonprofit donation pages:

• Placeholder text used as the only label, which disappears once someone starts typing and screen readers often skip it entirely.
• Preset donation-amount buttons or a button group that a screen reader announces as generic, unlabeled buttons rather than a set of choices.
• A recurring-donation toggle or checkbox whose state (on or off) isn't announced to assistive technology.
• Errors shown only through a red outline or color change, with no text explaining what went wrong or how to fix it.
• Validation errors that appear on screen but aren't announced to a screen reader, so the user has no idea the submission failed.
• Focus that jumps unpredictably, or gets lost entirely, when moving between steps in a multi-step donation flow.
• Payment fields missing standard autocomplete attributes, forcing people who rely on browser or assistive-technology autofill to type everything manually.
• A session timeout that logs a donor out mid-transaction with no warning and no way to extend the time.
• A CAPTCHA that depends entirely on visually identifying an image, with no accessible alternative.

How to make the form work with a keyboard and screen reader

• Give every field a real, programmatically associated label, not just placeholder text. Placeholder text can supplement a label; it should never replace one.
• Group related choices, such as preset donation amounts or payment method options, so a screen reader announces them as a set with a clear purpose, not as unrelated buttons.
• Make sure every interactive element, including custom amount buttons and toggles, is reachable and operable using only a keyboard.
• Keep a visible focus indicator on the currently selected element, so keyboard users can always see where they are.
• Keep focus order matching the visual order of the form, especially around dynamic elements like an "other amount" field that appears after a button is selected.

Handle errors and validation in an accessible way

This is where donation forms most often lose people. Three related WCAG criteria are directly relevant: Error Identification, which means an error is described in text, not just implied by color; Error Suggestion, which means the message explains how to fix the problem, not just that one exists; and Error Prevention, which applies specifically to forms that create a financial transaction.

• Describe errors in text near the relevant field, not only through a color change or icon.
• Explain what's wrong and how to fix it. "Invalid entry" tells a donor less than "Enter your card's 3-digit security code."
• Announce validation errors to screen readers when they appear, rather than relying on the user to notice a visual change.
• Before finalizing a donation, give the donor a way to review and correct the details, or make the transaction reversible. WCAG describes this requirement in full under its Error Prevention criterion for legal and financial transactions.

Multi-step and recurring donation flows

• Move focus deliberately at each step transition, typically to a heading or the first field of the new step, so keyboard and screen reader users know the page has changed.
• Announce progress in a way assistive technology can pick up, such as "Step 2 of 3," rather than relying on a purely visual progress bar.
• Build the recurring-donation option as a proper toggle, checkbox, or radio group with a clear, announced state, not a styled element that only looks interactive.
• If a session can time out, warn the donor before it happens and give them a way to extend it, rather than silently discarding their progress.

Third-party donation and payment platforms

Many nonprofits process donations through a fundraising or payment platform embedded in their site. Your organization doesn't control that vendor's code, but donors experience it as part of your website, and the accessibility of that experience is still worth evaluating before you commit to a platform.

• Ask the vendor directly about their accessibility testing process and which WCAG level they target.
• Ask for accessibility documentation, such as an Accessibility Conformance Report (ACR) based on the Voluntary Product Accessibility Template (VPAT), and review which standards and product features it actually covers rather than relying on a general accessibility claim.
• Test the embedded flow yourself with a keyboard and a screen reader before launch, since a vendor's general accessibility claims may not reflect how their widget behaves inside your specific page.
• Ask what happens when the vendor updates their platform, and how you would find out about a new accessibility issue introduced by that update.

Donation form accessibility checklist

Use this as a working checklist, not something to complete all at once. Start with whichever items affect the most donors on your specific form.

• Every field has a real, associated label, not just placeholder text.
• Group preset amount buttons and payment options, and announce them with a clear purpose.
• The entire form can be completed using only a keyboard, with a visible focus indicator throughout.
• Focus order matches the visual order, including around dynamic fields.
• Errors are described in text, explain how to fix the problem, and are announced to screen readers.
• Donors can review or correct their donation before it finalizes.
• Multi-step flows move focus deliberately and announce progress to assistive technology.
• The recurring-donation option has a clear, programmatically announced state.
• Payment and contact fields use standard autocomplete attributes where applicable.
• Session timeouts warn the donor and offer a way to extend the session.
• Any CAPTCHA has an accessible alternative to a purely visual challenge.
• Third-party payment or donation platforms have been tested directly, not assumed to be accessible based on a vendor's general claims.
• The form has been tested with both automated and manual accessibility testing, including real keyboard and screen reader use.

Where this fits within your broader accessibility and legal obligations

This article focuses on the practical fixes. Whether a specific legal obligation requires them depends on your organization's situation. If you haven't already, it's worth working through your nonprofit's ADA obligations, whether Section 504 applies because of federal funding, and which WCAG version and level fits your situation.

Regardless of which specific rule applies, reducing accessibility barriers in your donation flow can make it easier for more people to complete a donation.

Conclusion

You don't have to tackle every donation-form issue at once. Start with barriers that can prevent someone from completing a donation, such as missing labels, unclear errors, keyboard problems, and broken focus behavior.

Test what you have today, prioritize the highest-impact issues, and test again after a redesign or platform change.

For a broader review of your website, not just your donation form, our nonprofit website accessibility checklist is a good starting point.