Nonprofit Insights & Giving Tips

A donation form may be one of the most important pages on a nonprofit’s website. It turns interest into financial support and often serves people who are responding to an urgent appeal, attending an event, or learning about the organisation for the first time. If the form is difficult to read, navigate, understand, or submit, willing donors may leave before completing their gifts.

Accessibility barriers can affect people who use screen readers, keyboard navigation, voice controls, magnification, alternative input devices, or other assistive technologies. They can also affect people with low vision, limited mobility, cognitive disabilities, temporary injuries, or age-related changes. Many of the same improvements make the form easier for every donor using a phone, dealing with a slow connection, or trying to correct an error.

Improving donation form accessibility does not always require replacing the website or creating a new payment system. Many common problems can be corrected through clearer labels, better colour contrast, keyboard support, visible focus, understandable errors, and careful configuration of embedded payment tools. The first step is identifying where the current journey breaks.

Understand What WCAG Is Designed to Do

The Web Content Accessibility Guidelines, commonly called WCAG, provide a recognised framework for making digital content more accessible. The guidance is organised around four principles: content should be perceivable, operable, understandable, and robust.

Perceivable means donors must be able to obtain the information in a form, even if they cannot see the screen or distinguish colours. Operable means they must be able to use controls through a keyboard or another input method. Understandable means questions, instructions, and errors should be clear. Robust means the page should work reliably with browsers and assistive technologies.

WCAG includes testable success criteria at A, AA, and AAA levels. Many organisations work toward WCAG 2.2 Level AA, but the legal standard applying to a particular nonprofit can depend on its location, activities, funding, and audience. Qualified accessibility and legal professionals can help determine the appropriate obligations.

For a nonprofit, WCAG is best treated as a practical framework rather than simply a compliance checklist. A page can pass several automated checks and still be frustrating for someone trying to make a donation. The goal is to make the whole process usable, from the first donation link through payment and confirmation.

Begin With the Existing Donation Journey

Before making changes, complete the donation process from beginning to end. Start with the campaign or homepage link, select an amount, enter donor information, choose a payment method, review the gift, submit it, and read the confirmation.

The review should include more than the main form. Pop-up appeals, cookie notices, recurring-gift controls, address finders, payment windows, error messages, CAPTCHA challenges, and confirmation pages can all create barriers. A form may appear accessible until the donor reaches a third-party payment field that does not work with a keyboard.

Testing should use desktop and mobile devices, several browsers, keyboard-only navigation, zoom, and at least one commonly used screen reader. Automated tools can identify some problems, but they cannot determine whether every label makes sense or whether the entire donation experience is usable.

It can help to document the journey as a simple sequence:

• Find the donation page.
• Choose an amount and frequency.
• Enter personal and billing information.
• Select any designation or gift options.
• Complete payment.
• Receive confirmation and receipt information.

At each stage, ask a basic question: Can a donor understand what to do, complete the action, and recover if something goes wrong?

This approach is useful because accessibility problems are not always located in the form itself. A campaign page might contain an inaccessible donation link, or a confirmation page might provide critical information only through visual content.

Give Every Field a Clear Label

A visible label tells donors what information belongs in a field. It also gives assistive technology a name to announce when the user moves into that control. Name, email address, postal code, donation amount, and cardholder name should each have a programmatically connected label.

Placeholder text inside a field is not a reliable replacement. It disappears when the donor begins typing, may have weak contrast, and may not be announced consistently. A person reviewing the form can then forget what the field requested.

Labels should remain concise and specific. “Email address” is clearer than “Enter information.” If the organisation needs a billing postal code rather than a mailing postal code, the label should say so. Accurate language reduces errors and the need for lengthy instructions.

For donation forms with several similar fields, specificity becomes even more important. “Address” may not be enough when donors are asked for both billing and mailing addresses. Labels such as “Billing address” and “Mailing address” remove uncertainty.

The relationship between a label and its field should also be established in the underlying HTML, not just visually. This allows assistive technology to associate the correct instruction with the correct control.

Identify Required Fields Properly

Donors should know which fields must be completed before submitting the form. A visual asterisk can help, but it should not be the only indication. The form should explain what the symbol means and provide information that assistive technologies can recognise.

Avoid marking nearly every field as required without reviewing whether it is necessary. A long mandatory form creates friction and collects information the nonprofit must then protect. If a telephone number is used only for optional follow-up, requiring it may discourage people who do not want calls.

Optional questions should be identified where helpful. Donors should not have to guess whether they can leave tribute details, comments, demographic information, or marketing preferences blank.

A useful accessibility review should therefore consider not only whether a field is required, but why it is required. Every additional question adds another decision or task to the donation journey.

Keep the Form Keyboard Accessible

Some people cannot use a mouse or touch screen. They navigate through links, fields, buttons, and controls using a keyboard or alternative device. Every interactive part of the form should be reachable and usable without a pointer.

The focus order should follow the visual and logical sequence. It should move from the donation amount through contact information, payment details, consent options, and the submit button. Focus should not jump unexpectedly into navigation, return to the top of the page, or become trapped inside an embedded window.

Custom controls deserve close attention. Stylish donation buttons, sliders, calendars, dropdowns, and recurring-gift switches may look polished but fail to respond to standard keyboard commands. Native HTML controls are often more reliable when their appearance can meet the design requirements.

A simple keyboard test can reveal a surprising number of problems. Use the Tab key to move through the entire form, Shift+Tab to move backwards, and the expected keyboard controls for checkboxes, radio buttons, and other inputs. Make sure there is always a clear indication of where focus is located.

Make Keyboard Focus Easy to See

A keyboard user needs a visible indication of the element currently selected. Browsers often provide a focus outline, but website styling sometimes removes it for appearance. Without that indicator, the person may not know where the next action will occur.

The focus indicator should have enough contrast and remain visible around buttons, links, fields, checkboxes, and other controls. It should not be hidden behind a sticky header or clipped by a container.

Designers can style the outline to suit the brand without removing its function. A consistent, visible focus state supports both accessibility and faster navigation for people who prefer using the keyboard.

This is a relatively small change that can have a noticeable effect. There is usually no reason to remove the browser’s focus treatment unless a replacement is provided that is equally clear or better.

Use Colour With Sufficient Contrast

Text and essential controls need enough contrast against their backgrounds to remain readable. Light grey labels, pale placeholder text, and low-contrast buttons are common problems on visually minimal donation pages.

Contrast requirements depend on text size and whether the element is text, a graphical control, or a focus indicator. Organisations should test the actual colour codes rather than relying on visual judgement. A combination that looks clear on one display may be difficult to read in bright sunlight or with low vision.

Colour should not be the only way information is communicated. A required field should not be identified only by red text, and an error should not be shown only through a red border. Text, symbols, or other cues should explain the meaning.

Contrast should be checked across the whole donation experience, including:

• Form labels and instructions
• Button text and backgrounds
• Placeholder text where it conveys useful information
• Links
• Error and success messages
• Checkbox and radio-button states
• Keyboard focus indicators
• Disabled or selected controls where applicable

Testing the actual design is more reliable than assuming that brand colours will work everywhere. Accessibility can often be improved by making small adjustments to an existing colour palette rather than redesigning the page.

Let Donors Select an Amount Easily

Donation amount buttons should have clear text and a visible selected state. A donor needs to know whether $25, $50, or another option is active before proceeding. Assistive technology should also receive the selected status.

A custom-amount field should have its own label and accept values in a predictable format. Currency should be clear, particularly when the nonprofit accepts gifts from more than one country. Error messages should explain minimum or maximum limits without waiting until the final submission when possible.

Avoid controls that require precise dragging or tapping. Large amount buttons and a straightforward custom field work better across touch screens, keyboards, voice input, and alternative devices.

The selected state should also be understandable without colour alone. If the active amount changes background colour, for example, there should be another clear indication that it has been selected.

Explain One-Time and Recurring Gifts

Recurring donations can provide valuable predictable income, but donors must understand what they are authorising. The form should clearly distinguish a one-time gift from a weekly, monthly, quarterly, or annual contribution.

The selected frequency should remain visible near the amount and before payment submission. A donor should not need to infer that a highlighted button creates an ongoing charge. Confirmation messages and receipts should repeat the amount and schedule.

Controls should not use confusing defaults or design that makes one option difficult to see. Accessible design supports informed choice. It should never be used only to technically meet a standard while the interface encourages accidental recurring commitments.

This is particularly important because accessibility and transparency overlap here. A donor who has difficulty seeing a selected state or understanding a control should not be placed at greater risk of making an unintended financial commitment.

Write Instructions in Plain Language

Donation forms often include explanations about gift designations, tax treatment, matching, processing fees, anonymity, and recurring payments. These instructions should use direct language and appear where donors need them.

Long legal or promotional passages placed between fields can interrupt navigation. Important information should be concise, while longer policies can be linked without hiding terms that affect the transaction.

Unfamiliar abbreviations and internal programme names should be explained. Donors should not need detailed knowledge of the nonprofit’s structure to choose the right fund or understand where a gift will go.

Plain language is also helpful for people with cognitive disabilities, people using translation tools, and donors who are simply in a hurry. Short instructions such as “Choose how often you want to give” are easier to act on than internal terminology or marketing language.

Create Errors That Help People Recover

A form should not simply announce that “something went wrong.” It should identify which field needs attention, explain the problem, and tell the donor how to correct it. “Enter an email address in the format name@example.com” is more useful than “invalid input.”

Errors should appear near the affected field and be communicated to assistive technology. If the form shows a summary at the top, each message can link to the corresponding field. Focus should move in a predictable way so the donor can begin correcting problems.

The form should preserve valid information after an error. Clearing every field because a postal code was missing forces the donor to repeat work and may lead to abandonment.

Error messages should also avoid blaming the donor. “We couldn’t process this postal code” is generally more useful than “You entered the wrong information.” Where appropriate, the message can explain formatting requirements before the donor tries again.

Do Not Depend on Colour for Errors

A red outline around a field may be invisible or unclear to some donors. It also does not explain why the information was rejected. The form should provide a text message and, where appropriate, a recognisable icon with an accessible meaning.

Error styling should remain visible at higher zoom levels and on mobile screens. Messages should not be covered by the on-screen keyboard or placed far from the field.

Success states need similar clarity. If an address has been accepted or a promotional match applied, that information should be available to people who cannot see a colour change or visual animation.

Support Zoom and Reflow

People with low vision may enlarge the page significantly. The donation form should reflow so content remains readable without requiring horizontal scrolling for ordinary text. Fields, labels, buttons, and messages should not overlap or disappear.

Fixed-height containers are a common source of problems. When text becomes larger, instructions may be clipped or controls may cover each other. Embedded forms should also have enough height to display expanded content and errors.

Mobile-responsive design helps but does not guarantee accessible reflow. The page should be tested at increased browser zoom and with larger text settings. The user should still be able to reach and submit every control.

This is another reason not to treat desktop testing as sufficient. A form can look perfectly usable at its normal size and then become difficult to operate when text is enlarged. Testing the actual donation page under different display conditions can identify these problems before donors encounter them.

Make Touch Targets Easier to Use

Small checkboxes, closely spaced amount buttons, and tiny links are difficult for people with limited dexterity and for anyone using a phone. Controls should provide enough space for reliable selection without accidentally activating a neighbouring option.

The clickable area can include the associated label, not just the small visual box. This makes consent choices, gift designations, and recurring-payment options easier to use.

Spacing should remain consistent across screen sizes. A desktop form may provide adequate separation while the mobile version compresses several controls into one narrow row. Testing with real devices can reveal these issues.

Touch accessibility also benefits people who are using a device while walking, carrying something, or dealing with temporary limitations. Making important controls easier to tap is a practical usability improvement, not just an accessibility exercise.

Use Autocomplete Where Appropriate

Browsers and assistive tools can help donors enter names, addresses, telephone numbers, and payment information when fields use recognised autocomplete purposes. This reduces typing and benefits people with mobility, memory, or cognitive difficulties.

Autocomplete should be implemented using standard attributes rather than guessed from field labels. The page should not disable paste in email or payment fields because pasting can reduce mistakes and support password or data-management tools.

Prefilled information should remain editable. A donor using a saved address may need to correct an outdated postal code or choose a different billing address. Convenience should not remove control.

Handle CAPTCHA Without Creating a New Barrier

Nonprofits need to protect donation forms from bots, spam, and card-testing attacks. Traditional image CAPTCHA challenges can create serious barriers for people with visual, cognitive, and other disabilities. Audio alternatives can also be difficult to understand.

Modern risk-based tools may evaluate behaviour in the background and show a challenge only when needed. The selected solution should offer accessible alternatives and work through a keyboard and assistive technology.

CAPTCHA should form one part of a broader fraud strategy. Server-side validation, rate limits, session controls, payment-provider fraud tools, and monitoring can reduce dependence on difficult challenges. Security and donation form accessibility should be planned together.

Check Embedded and Third-Party Payment Fields

Many donation pages use a form, iframe, payment component, digital wallet, or hosted checkout supplied by another company. The nonprofit may not control the component’s code, but donors still experience it as part of the organisation’s website.

The provider should be asked about WCAG conformance, keyboard support, screen-reader testing, focus management, error handling, and current accessibility documentation. A conformance statement can provide useful information, but the actual integration must still be tested.

Custom styling or scripts can introduce barriers into an otherwise accessible payment component. Updates can also change behaviour. The organisation should test the complete transaction after modifying the website or installing a new version of a plugin.

Third-party accessibility should therefore be part of vendor selection, not an afterthought. Before adopting a new donation or payment tool, ask:

• Does the provider document accessibility testing?
• Can the payment fields be completed using only a keyboard?
• Are error messages available to screen-reader users?
• Can focus move into and out of embedded content predictably?
• Does the provider have a process for reporting accessibility issues?
• Will accessibility be maintained as the service is updated?

The nonprofit may not control the vendor’s roadmap, but it can choose vendors carefully and make accessibility expectations clear.

Give Payment Buttons Meaningful Names

The final button should explain what happens when it is activated. “Donate $50,” “Complete Donation,” or “Submit Monthly Gift” gives the donor more information than “Continue,” especially when several steps are involved.

The button label should match the transaction state. If another review page follows, “Review Donation” is more accurate than “Donate Now.” If activation submits payment immediately, the language should make that clear.

Loading states need to be communicated as well. After submission, the button can become unavailable while the payment processes, and assistive technology should receive an appropriate status. This reduces duplicate transactions caused by repeated clicks.