Accessible Forms: How to Build Contact and Donation Forms Everyone Can Use
Your contact form is the front door to your organization. Your donation form is the cash register. Your volunteer signup is the handshake. Every single one of these moments matters.
And every single one of them can fail if the form isn't accessible.
Accessible web forms aren't a nice extra. They're the difference between someone completing a donation and someone giving up in frustration. For nonprofits, churches, and HOAs, forms are where engagement becomes action. When those forms exclude people with disabilities, you're not just breaking compliance rules. You're losing real support from real people who want to help.
Why Forms Are the Biggest Accessibility Failure Point
Forms are interactive. They demand input, attention, and decisions. That makes them harder to get right than static content like paragraphs and images.
According to the WebAIM Million study, form-related failures are among the most common accessibility issues found on the web. Missing form labels alone affect over 45% of home pages surveyed. That's nearly half of all websites failing at something this basic.
The consequences are real. A blind user hits a form field and their screen reader announces... nothing. Just "edit text." No clue what information goes there. A keyboard user tabs through the form and can't tell which field is focused. A person with low vision can't find the error message because it only appears at the top of the page in tiny red text.
These aren't edge cases. These are everyday experiences for millions of people.
The Most Common Form Failures (and How to Fix Them)
Placeholder Text Instead of Labels
This is the single most common form accessibility mistake. Designers love the clean look of placeholder text inside input fields. No visible labels, just ghostly gray text that disappears when you start typing.
Here's why that fails. Placeholder text vanishes the moment someone clicks into the field. Now they can't remember what goes there. Screen readers may or may not announce placeholder text depending on the browser and assistive technology combination. And that light gray placeholder color almost never meets color contrast requirements.
The fix: Every form field needs a visible `<label>` element connected to the input via matching `for` and `id` attributes. The label stays visible at all times. You can still use placeholder text as a hint (like "e.g., jane@email.com"), but it should never replace the label.
Vague or Missing Error Messages
"Invalid input." What does that mean? Is the email wrong? The phone number? Is it the format? The length?
Unhelpful error messages frustrate everyone, but they're especially harmful for screen reader users who may not be able to visually scan the form to figure out what went wrong. If the error message only appears at the top of the page, a screen reader user might not even know it exists.
The fix: Place error messages inline, right next to the field that has the problem. Be specific: "Please enter a valid email address" is far better than "Invalid input." Connect the error message to the field using `aria-describedby` so screen readers announce it when the user focuses the field.
No Keyboard Navigation
If you can't tab through every field, select every option, and submit the form using only your keyboard, the form is broken for keyboard users. This includes people who use screen readers, switch devices, voice control, and anyone who simply prefers keyboard navigation.
The fix: Use native HTML form elements (`<input>`, `<select>`, `<textarea>`, `<button>`) instead of custom-built alternatives. Native elements come with keyboard support built in. If you must use custom components, make sure they respond to Tab, Enter, Space, and arrow keys appropriately. Test by putting your mouse in a drawer and filling out the form with your keyboard alone.
Missing Focus Indicators
When you tab through a form, you need to see which field is currently active. Many designers remove the browser's default focus outline because they think it looks ugly. That blue ring around a focused input? It's there for a reason.
The fix: Never remove focus indicators with `outline: none` without providing a replacement. Design a custom focus style that fits your brand: a colored border, a box shadow, a background change. Make it obvious. Check that it meets the WCAG 2.1 AA requirements for focus appearance.
CAPTCHA That Blocks Screen Readers
Traditional image CAPTCHAs are nearly impossible for screen reader users. Even audio alternatives are often garbled and frustrating. If your form requires solving a visual puzzle to submit, you're locking out a significant number of people.
The fix: Use Google reCAPTCHA v3, which works invisibly in the background with no user interaction required. Or use honeypot fields (hidden fields that only bots fill out) as a spam prevention technique that doesn't burden real users at all.
Required Fields Marked Only by Color
A red asterisk next to a field label means "required" to most sighted users. But if you only use the asterisk without explaining what it means, and you only differentiate it by color, you've excluded people with color vision deficiency and screen reader users.
The fix: Add the text "(required)" to the label, or include a note at the top of the form explaining that asterisks indicate required fields. Use the `required` attribute on the HTML element so screen readers announce it. And use `aria-required="true"` as a backup.
How to Build Accessible Forms Step by Step
Here's your checklist for every form you build.
1. Label Every Field
```html <label for="email">Email Address (required)</label> <input type="email" id="email" name="email" required aria-required="true"> ```
The `for` attribute on the label matches the `id` on the input. This creates a programmatic connection that screen readers rely on. Clicking the label also focuses the input, which helps people with motor impairments who struggle to click small targets.
2. Group Related Fields
When you have a set of related fields (like a mailing address or a set of radio buttons), wrap them in a `<fieldset>` with a `<legend>`.
```html <fieldset> <legend>Mailing Address</legend> <label for="street">Street Address</label> <input type="text" id="street" name="street"> <label for="city">City</label> <input type="text" id="city" name="city"> </fieldset> ```
The legend gives context to the group. Without it, a screen reader user hearing "City" has no idea which address you mean if the form has both a billing and shipping section.
3. Add Help Text with aria-describedby
Sometimes a label isn't enough. You need to explain the expected format or provide additional instructions.
```html <label for="phone">Phone Number</label> <input type="tel" id="phone" name="phone" aria-describedby="phone-help"> <span id="phone-help">Format: (555) 555-5555</span> ```
The `aria-describedby` attribute tells screen readers to announce the help text after the label. The user hears "Phone Number, format 555-555-5555" and knows exactly what to type.
4. Handle Errors Clearly
When validation fails, put the error message right next to the field and connect it programmatically.
```html <label for="email">Email Address (required)</label> <input type="email" id="email" name="email" aria-describedby="email-error" aria-invalid="true"> <span id="email-error" role="alert">Please enter a valid email address.</span> ```
The `aria-invalid="true"` attribute tells screen readers the field has an error. The `role="alert"` on the error message makes screen readers announce it immediately when it appears.
5. Make Submit Buttons Real Buttons
Use a `<button>` element for your submit action. Not a `<div>` styled to look like a button. Not an `<a>` tag. A real button.
```html <button type="submit">Send Your Message</button> ```
Native buttons are keyboard accessible, announced properly by screen readers, and work with assistive technology out of the box.
Donation Form Specifics
Donation forms have unique accessibility challenges. If you're a nonprofit or church relying on online giving, getting this right directly affects your revenue.
Preset Amount Buttons
Those "$25 / $50 / $100 / Custom" buttons need to work with a keyboard. Each one should be a real `<button>` or a radio input, not a clickable `<div>`. When selected, the button should have a clear visual state change and announce "selected" to screen readers.
Payment Fields
If you're using a third-party payment processor like Stripe, make sure their embedded fields are accessible. Stripe Elements, for example, has built-in accessibility support, but you still need to provide visible labels above each field. Don't rely on the placeholder text inside the card number field.
Recurring Giving Toggle
A "Make this a monthly gift" checkbox or toggle needs a clear, visible label. If you're using a custom toggle switch instead of a native checkbox, add `role="switch"` and manage the `aria-checked` state. Test it with a keyboard to make sure Enter or Space activates it.
Confirmation Messages
After a successful donation, show a clear confirmation message on the page. Don't just redirect silently. Use `role="status"` or `role="alert"` so screen readers announce the success. Include the amount and any confirmation details. If you email a receipt, say so on the page.
Testing Your Forms for Accessibility
You don't need to be an accessibility expert to test your forms. You just need to do three things.
1. Tab Through the Entire Form
Put your mouse aside. Start at the top of the page and press Tab. Can you reach every field? Can you see where the focus is? Can you select radio buttons and checkboxes with Space? Can you submit with Enter? If you get stuck anywhere, keyboard users will too.
2. Try a Screen Reader
On a Mac, turn on VoiceOver (Cmd + F5). On Windows, download NVDA for free. Navigate your form and listen. Does every field announce its label? Do error messages get read? Can you understand what's being asked without looking at the screen?
3. Run an Automated Scan
Install the axe DevTools browser extension and scan your form page. It catches missing labels, broken aria attributes, and contrast failures automatically. It won't catch everything (you still need the manual tests above), but it's a fast way to find obvious issues.
Forms Are Where the Work Happens
Your website's static pages tell your story. Your forms are where people respond to it. Every missed donation, every abandoned contact form, every frustrated volunteer who gave up on your signup page is a real loss for your mission.
Building accessible forms isn't just about compliance. It's about making sure that when someone wants to support your organization, nothing stands in their way.
Start with your most important form. Your donation page or your contact form. Tab through it. Test it with a screen reader. Fix what's broken. Then move to the next one. Every form you fix is another barrier removed.
