Forms are where a website asks people to do something. Request a quote. Book a cleaning. Register for the open house. Join the waitlist. When a form fails someone who is blind, has low vision, has a tremor or simply cannot use a mouse, you do not get a complaint most of the time. You get nothing. The inquiry never arrives, and from your side the form looks like it is working fine.
This page explains our accessible form fixes for WordPress sites: the contact, quote, booking, registration, application and newsletter forms that bring in your leads and appointments. We cover how we test each one, what we usually change, how we deal with form plugins and CAPTCHA, what you receive at the end and what we will and will not claim about the result. It is one of the services in our US website accessibility program.
Where forms quietly fail people
Most broken forms look fine. The trouble is in what you cannot see. A field with gray placeholder text and no real label reads to a screen reader as “edit text, blank”, so the user has to guess whether it wants a name or a phone number. A required asterisk drawn in red tells nothing to someone who cannot see red. An error message that appears in a box at the top of the page is never heard by a user whose cursor is still sitting on the Submit button.
Here is a short test you can try right now on your own contact page. Click into the first field and put your mouse away. Press Tab to move through the fields, type something in each, use the Space bar to tick a checkbox, then press Enter on the button. Did you see where you were at every moment? Could you pick a date? Did the thank-you message appear somewhere you noticed? If any answer is no, the form is losing people.
On form work we cite a familiar handful of WCAG 2.2 criteria again and again: Labels or Instructions (3.3.2), Error Identification (3.3.1), Info and Relationships (1.3.1), Status Messages (4.1.3), Name Role Value (4.1.2), and Headings and Labels (2.4.6). The newer criteria 3.3.7 Redundant Entry and 3.3.8 Accessible Authentication (Minimum) matter for multi-step forms and logins.
What our accessible form fixes cover
We work through every form you rely on, not just the one on the contact page. A typical set includes:
- Labels. Each field gets a visible label connected to it in code, so clicking the label focuses the field and screen readers read it aloud. Placeholders stay only as hints, never as the only label.
- Grouping. Radio buttons and checkbox sets get a group label (“Preferred contact method”) so each option makes sense on its own.
- Instructions. Format rules (“MM/DD/YYYY”, “at least 8 characters”) appear before the field and are tied to it, not hidden in a tooltip.
- Required fields. Marked in text as well as with a symbol, explained once at the top, and set as required in code so assistive technology knows.
- Autocomplete. Name, email, phone and address fields get the correct autocomplete values so browsers and password managers can fill them.
- Errors. Each error names the field and says how to fix it, appears next to the field, is announced and moves focus sensibly.
- Success messages. The confirmation is announced, or the form leads to a thank-you page with a clear heading.
- Keyboard and focus. Every control works with a keyboard, focus is always visible and nothing sticky hides the focused field.
- Touch and zoom. Buttons and checkboxes meet the 24 by 24 CSS pixel target size, and the form still works at 200 percent zoom and at narrow widths.
Layout and design theory belong to the design stage; this page is about repairing forms already in use.
How we test a form before touching it
For each form, we run the same sequence. First a keyboard-only pass, filling it in correctly. Then a second keyboard pass, filling it in badly on purpose: skipping required fields, typing letters into the phone field, entering an email without the @ sign. Errors are where most forms fall apart, so we spend real time there. Our guide to writing error messages that get announced goes deeper on what good errors look like.
Next we repeat both passes with NVDA on Windows and VoiceOver on an iPhone, listening for what each field is called, whether instructions are read, whether the error is heard and whether the success message arrives. We zoom the browser to 200 percent, narrow the window to phone width and check the date pickers, file upload buttons and dropdowns again. An automated scan runs alongside, but scanners can confirm only part of this. A scanner will notice a missing label. It cannot tell you that the label says “Field 4”.
Every issue goes into a findings list with the form name, the page, the steps to reproduce, the WCAG criterion and the fix we propose.
Form plugins: what they handle and where we step in
Most WordPress forms come from a plugin: Contact Form 7, Gravity Forms, WPForms, Ninja Forms, Formidable, Fluent Forms, or the form widget inside Elementor or Divi. Some plugins have put real work into accessible output. Others leave much of it to whoever builds the form. And the same plugin can produce a good form or a bad one depending on how the fields were set up and how the theme styles them.
| What breaks | Usual cause | How we fix it |
|---|---|---|
| Labels missing or hidden | Builder set to “placeholder only” or a theme style that hides labels | Restore visible labels in the form settings, adjust the theme CSS |
| Errors not announced | Plugin shows errors visually only, or a theme overrides its markup | Use the plugin’s accessible error option where offered; add a small script to announce and move focus |
| Required not conveyed | Asterisk added as text in the label with no required attribute | Mark fields as required in the builder; explain the asterisk once |
| Date picker unusable | Third-party calendar script with mouse-only controls | Allow typed dates, switch to the browser’s native date input or a tested picker |
| Contact Form 7 layout issues | Fields written by hand in the form template without label tags | Rewrite the template with proper labels and groups |
| Success message missed | Message injected silently where the form was | Announce it as a status message or redirect to a thank-you page |
We work inside the plugin’s settings first, then in the form template, then with CSS and small scripts in a child theme or site plugin. We avoid editing plugin files, because updates overwrite them. If a plugin simply cannot produce an accessible form, we tell you and suggest what to rebuild it in. Plugin-by-plugin notes for owners are in our article on checking a WordPress contact form plugin.
CAPTCHA, spam protection and accessible authentication
Spam is a real problem, and turning off protection is not the answer. But the puzzle-style CAPTCHA is one of the most common reasons a disabled visitor gives up. Distorted letters, picture grids of crosswalks and audio clips of muffled numbers are hard or impossible for many people. On a login or registration form, criterion 3.3.8 Accessible Authentication (Minimum) asks that signing in does not depend on a cognitive test, such as remembering or transcribing characters, unless an alternative or help is offered.
Our usual approach, in order of preference:
- Server-side spam filtering and honeypot fields, which block most bots without asking the human to do anything.
- Invisible or score-based checks that only challenge suspicious submissions, with the challenge itself checked by keyboard and screen reader.
- If a visible challenge has to stay, one with an accessible alternative, and a clear route to contact you another way.
We test the spam setup with real submissions afterward, because a filter that blocks bots and also blocks your customers is no improvement. For more on the trade-offs, see our post on CAPTCHA alternatives that do not lock people out and the existing guide to stopping contact form spam without losing leads.
Multi-step, booking and registration forms
Long forms split into steps can be easier for everyone, if they are built well. When they are not, a screen reader user presses Next and lands on silence: the new step loaded, but focus stayed on a button that no longer exists. We check that each step announces where the user is (“Step 2 of 4: Your address”), that focus moves to the start of the new step, that Back keeps what was entered and that information given in an earlier step is not demanded again (3.3.7 Redundant Entry).
Booking forms for clinics, salons, law offices and restaurants bring their own problems: calendar grids that only work with a mouse, time slots shown as colored boxes, and session timeouts that wipe the form after a few minutes. We make the calendar keyboard-operable or offer a typed alternative, label each slot with its date and time, and make sure any timeout warns the user and allows more time. The booking side is explored further in our guide to appointment booking forms that work for everyone. If you are building a stepped form from scratch, our walkthrough on building a multi-step form in WordPress explains the setup; we then test what it produces.
Registration and job application forms often include file uploads. We check that the upload button has a clear name, that the allowed file types and size are stated before the user picks a file and that an upload error is announced.
A word on checkout and store forms
A WooCommerce checkout is a form too, but it carries payment iframes, live shipping updates and cart logic that ordinary forms do not. We handle that on our WooCommerce store accessibility page. Store forms that are not part of checkout, such as wholesale applications, back-in-stock alerts or product inquiries, fit within the form work described here.
What you receive, and what we ask you for
When the work is done you have:
- An inventory of every form on the site, which page it lives on and which plugin builds it.
- A findings list per form, with each issue’s criterion, status and how we verified the fix.
- A record of the test submissions we made after fixing, including the screen readers and browsers used.
- A note of any change made outside the plugin settings, with its location.
- Short guidance for whoever edits forms on your team: how to add a field with a proper label, how to write an instruction, what not to switch off.
To start we need WordPress administrator access, a list of the forms that matter most to your business (if you are not sure, we will find them), a safe email address to receive test submissions, and to know where submissions go, such as a CRM, a spreadsheet or a booking system, so our test entries do not confuse your staff. A staging site is helpful but not required for most form work. Our existing guide on testing WordPress forms before customers do covers the delivery side, which we check as well.
Judging the result without being an expert
Repeat the keyboard test from the start of this page on each form. Then turn on VoiceOver on your iPhone (it is in the Accessibility settings) and try to fill in the contact form by swiping. You should hear each field’s name, hear the error if you skip a required field and hear or see a clear confirmation. You should not need to guess at any point.
Some honest limits: we can make the forms on your site work well, but if a form is an embed from another service (a scheduling tool, a payment form, a survey app), we can fix the page around it, test the embed and report what fails, but the code inside belongs to that vendor. We will list such embeds separately so they are not mistaken for finished work. We also do not claim that fixing forms makes a site conform to WCAG 2.2 AA as a whole; forms are one part of it.
Common mistakes we see owners and developers make:
- Hiding labels to make a form look minimal, then relying on placeholders that vanish as soon as someone types.
- Adding aria attributes by guesswork, which can make a working form worse.
- Fixing the contact form but forgetting the newsletter box in the footer and the popup signup.
- Changing one form’s styling in a way that breaks focus outlines on every other form.
Fixing forms yourself versus bringing us in
Plenty of accessible form fixes are within reach for a careful site owner: turning on visible labels in the plugin, writing clear instructions, explaining required fields, removing a puzzle CAPTCHA in favor of the plugin’s honeypot option. Do those first. Where it gets harder is error announcement, focus handling in multi-step forms, custom date pickers and theme CSS that interferes with every form at once.
If you hire someone, whether that is us or another provider, ask:
- Will you test each form with errors, not only with correct entries?
- Which screen readers will you use, and on what devices?
- Where will changes live so plugin updates do not erase them?
- How will you handle embedded third-party forms?
- Will you check that submissions still reach us after the changes?
The last question matters more than it sounds. An accessibility fix that breaks email delivery is a step backward.
Keeping forms usable as the site changes
Forms change more often than most pages. A staff member adds a field for a new service. A plugin update changes its error markup. A marketing tool injects a popup signup. Each of these can undo careful work without anyone noticing, because the form still submits for the people who test it.
We suggest re-running the keyboard and screen reader checks on your key forms after form plugin updates, whenever a form is edited and as part of regular monthly accessibility checks. Accessible web forms are part of a broader WordPress site that also needs maintaining; our work on WordPress themes, menus and plugins covers the rest of it, and the form checks slot into the same routine. For anyone wanting the original wording of the criteria above, the W3C Web Accessibility Initiative publishes tutorials on forms alongside the standard itself.