Before launch, test who your donation form leaves behind

Test a donation form by completing every enabled giving path without a mouse, checking that each control has an understandable label, forcing mistakes to see whether the form explains and preserves the donor's work, and verifying that the final status is clear. Stop the launch when a donor cannot reach, understand, correct, or confirm a required step.

That is a useful nonprofit donation form accessibility gate. It does not certify legal or technical conformance. It tells a small fundraising team whether the real giving path has a reproducible blocker and who needs to fix it.

Build a small test matrix

List the paths a donor can actually take. Include one-time and recurring giving, each payment method, the mobile layout, and any hosted page or embedded widget. Add campaign-specific choices such as a fund, tribute, or optional fee only when they are enabled.

For each path, record four pass conditions:

1. Reach: Can the tester move to every required control and activate it without a mouse?
2. Understand: Does each field, choice, amount, and button have a clear name and instruction?
3. Recover: When an entry is missing or invalid, can the tester find the problem, understand the fix, and continue without redoing unrelated work?
4. Confirm: After submission, is the result unmistakable, and can the tester tell what happens next?

Use the production-like path your campaign will send people to, but follow your payment provider's approved test method. Do not improvise with real card details. The separate donation-form prelaunch test picks up after submission and follows the gift through payment, receipt, attribution, and staff records.

Run the first pass without a mouse

Start at the campaign link and put the mouse aside. Use Tab and Shift+Tab to move, Enter or Space to activate controls, and arrow keys where a choice group requires them. Watch for the visible focus indicator as you move.

The test fails when focus disappears, jumps in an order that changes the meaning, becomes trapped inside a widget, skips a required choice, or cannot reach the submit control. Record the first failed step rather than collecting a vague note such as “keyboard issue.”

W3C's preliminary accessibility checks specifically call for checking keyboard access to all form controls, including items in drop-down lists. A fundraising operator can reproduce that test even when the technical repair belongs to a web developer or platform provider.

If your form is embedded, test entry into and exit from the embedded payment area. If that boundary fails, capture the page URL, device, browser, payment path, last working control, key pressed, expected result, and observed result. The embedded-versus-hosted form guide helps decide whether the surrounding website or the hosted path is the safer campaign route while the defect is being fixed.

Check what every control is called

A visible prompt is not enough if the control and its name are not connected. Listen with a screen reader available to your team, or use your browser's accessibility inspection tools, and move through the same path again. For each control, ask whether the announced name explains the choice without relying on position, color, or nearby decoration.

W3C's forms guidance says labels should describe a control's purpose and be associated with that control. The connection supports screen-reader and speech-input users and also gives small controls such as checkboxes a larger clickable target.

Pay special attention to donation amounts, recurring-frequency choices, required indicators, card fields, consent boxes, and the final button. “Option one,” an unlabeled amount, or a required field indicated only by color does not give the tester enough information to proceed confidently.

Force errors and preserve the donor's work

Submit once with a required field blank. Then enter a badly formatted email or another safe invalid value. A useful error tells the tester what failed, identifies the affected field, and explains what to do next. The message should be findable when it appears; changing a border color alone is not a complete explanation.

W3C's explanation of error identification says an unsuccessful submission must do more than redisplay the form and that errors need a text description or text alternative. Its preliminary checks also recommend confirming that fields without errors remain populated, apart from sensitive data that should not persist.

Test that recovery, not just the error message. Correct the failed field and continue. If the amount, designation, donor details, or recurring choice disappears, record the data loss as part of the same blocker. A donor who understands the message can still be unable to finish if the form makes them rebuild the gift.

Save the first failure as an owned task

One failure record should contain:

• path and page URL;
• device, browser, and input method;
• exact step and control;
• expected and observed behavior;
• screenshot or short recording when useful;
• severity, owner, and retest date.

Prioritize blockers that prevent completion before cosmetic inconsistencies. Retest the same path after a repair, then rerun the other enabled paths because a shared form or payment component may affect more than one campaign.

This operator pass is a floor, not the finish line. Automated checks can help find certain defects, but they cannot prove that the whole giving experience works for disabled donors. Pair the launch gate with feedback and testing from people who use different assistive technologies, and involve a qualified accessibility specialist when your organization needs a formal assessment.