Every day, people with disabilities attempt to fill out contact forms, checkout flows, newsletter signups, and login screens on WordPress sites — and fail. Not because they lack ability, but because the forms themselves are broken for anyone who relies on a screen reader, keyboard navigation, or voice control. Form accessibility is one of the highest-impact areas you can fix on your site, and it’s also one of the most commonly overlooked.
Why Forms Are an Accessibility Minefield
Forms require users to understand what information is needed, provide it correctly, and get meaningful feedback when something goes wrong. For sighted users with a mouse, this usually works without much thought. For users who navigate by keyboard or use a screen reader, every missing label, ambiguous error message, and poorly marked required field is a potential dead end.
WCAG 2.2 — the current standard referenced by the ADA and the European Accessibility Act — dedicates an entire principle (Guideline 3.3) to helping users avoid and correct mistakes. Forms that fail these criteria aren’t just inconvenient; they put you at legal risk and actively exclude a significant portion of your audience.
The Three Biggest Form Accessibility Failures
1. Missing or Broken Labels
The most common form accessibility issue is a missing <label> element. When a screen reader lands on an input field with no label, it announces something like “edit text” — giving the user no idea what they’re supposed to type. Placeholder text is not a substitute for a label. Placeholder text disappears when someone starts typing, is often low-contrast by default, and is not reliably announced by all screen readers.
Every input, select, and textarea in your forms needs a programmatically associated label. The most reliable method is a visible <label> element with a for attribute matching the input’s id. If your design calls for visually hidden labels, you can hide them with CSS (using a visually-hidden utility class) — but they still need to exist in the HTML.
2. Inaccessible Error Messages
When a user submits a form incorrectly, what happens? On many WordPress sites, a red border appears on the problem field, or a small message appears somewhere on the page. If a screen reader user isn’t told where to look, they may have no idea an error occurred at all.
Accessible error handling requires two things. First, errors need to be announced — either by moving focus to an error summary at the top of the form, or by using aria-live regions that announce errors as they appear. Second, each error message needs to be explicitly associated with its field using aria-describedby, so when the user tabs back to the field, the screen reader reads both the label and the error together.
3. Unmarked Required Fields
Indicating required fields only with a red asterisk (*) and a note at the top of the form fails users for two reasons: color alone can’t be relied upon to convey meaning, and the convention isn’t universally understood. WCAG 1.3.1 requires that information conveyed through visual presentation also be available programmatically.
The correct approach is to use the required attribute on the input element (which browsers and screen readers understand natively) and to include visible text — either “(required)” near the label or a clear legend — rather than relying on color or symbols alone.
What Accessible Forms Look Like in Practice
Here’s a practical checklist for every form on your WordPress site:
- Every input has a visible label — not just placeholder text, a tooltip, or an icon
- Labels are programmatically associated with their inputs using
for/idoraria-labelledby - Required fields use the
requiredattribute and have visible text indicating they’re required - Error messages are specific — “Please enter a valid email address” rather than “Invalid input”
- Errors are associated with their fields using
aria-describedby - Focus is managed after submission — either moved to an error summary or to the first field with an error
- Success messages are announced — use an
aria-liveregion or move focus to the confirmation - Fields have sufficient color contrast — both the label text and any border/outline on the input itself
- Autocomplete attributes are used where appropriate —
autocomplete="email",autocomplete="name", etc. (WCAG 1.3.5)
Common WordPress Form Plugins and Their Accessibility Track Record
Most popular WordPress form plugins have improved their accessibility over the years, but none are perfect out of the box. Here’s what to watch for:
Contact Form 7 generates reasonably accessible markup when configured correctly, but its default error handling doesn’t always move focus appropriately after a failed submission. Multi-step forms require extra attention.
Gravity Forms has made significant accessibility investments and offers better error handling than many alternatives. However, conditional logic fields — fields that appear or disappear based on other inputs — need careful testing to ensure screen readers announce the changes correctly.
WPForms and Formidable Forms vary in accessibility depending on the template and settings used. Custom styling applied to make forms match your theme can inadvertently remove focus indicators or reduce contrast.
Regardless of which plugin you use, always test your forms with keyboard-only navigation and at least one screen reader before launch. Tab through every field. Submit with errors intentionally. Make sure you can complete the entire flow without a mouse.
The Honest Reality About Automated Scanning
Automated accessibility scanners can catch some form issues — missing labels, low contrast on input text, and obvious ARIA errors are detectable by tools. But they can’t catch everything. A scanner won’t know whether your error messages make sense, whether focus lands in the right place after submission, or whether your multi-step form correctly manages state for screen reader users.
Think of automated scanning as a first pass that catches the most common, clear-cut violations. Manual testing — especially with real assistive technology — is still necessary to find the subtler issues that matter most to actual users.
Take Action
If you’re not sure whether your WordPress forms are accessible, start with a scan. LEWCA’s free WordPress plugin will analyze your site’s code and flag real accessibility issues — including missing labels, contrast failures, and ARIA problems — rather than just overlaying a widget and hoping for the best. If you need deeper analysis, scheduled scanning, and AI-powered code fix suggestions, LEWCA Pro gives you the tools to work through issues systematically and document your progress. Forms are one of the most impactful places to invest your accessibility effort — start there.