A form that looks fine visually can still be completely unusable for someone navigating with a keyboard, or unreadable for someone using a screen reader. Accessibility issues on forms don’t show up in a normal visual review. They only show up when someone who actually needs them tries to use the form and can’t.

Here’s the checklist I run every form through before it goes live.

Worth saying upfront: most reputable WordPress form plugins (Gravity Forms, WPForms, Contact Form 7 with proper setup) handle a good chunk of this correctly out of the box. That’s not a reason to skip the check, it’s a reason to actually verify it on your specific form rather than assume. The fastest way to know where you stand is to try it yourself, tab through your own form, turn on a screen reader for five minutes, and see what happens.

How to use labels for accessible forms?

• Every input needs a real <label> element connected to it, not just placeholder text sitting inside the field. Placeholder text disappears the moment someone starts typing, and screen readers don’t always announce it the same way as a proper label.
• Labels should describe what’s being asked, not just repeat the field name. “Email address” is clearer than just “Email.”
• Required fields need to be marked in a way that’s announced audibly, not just shown with a red asterisk. A screen reader user needs to hear “required,” not just see a symbol.

How to create accessible error messages in forms?

• Error messages need to be linked directly to the field they’re describing, using aria-describedby, so a screen reader announces the error alongside the field, not as a disconnected message somewhere else on the page.
• Errors should describe what’s wrong and how to fix it. “Invalid input” tells the visitor nothing. “Enter a valid email address, e.g. name@example.com” tells them exactly what to change.
• Color alone should never be the only indicator of an error. Red borders help sighted users, but they’re invisible to a screen reader and unreliable for visitors with color blindness. Pair color with text and, where possible, an icon.

Keyboard navigation

• Every field, button, and interactive element on the form needs to be reachable using Tab alone, no mouse required.
• Tab order should follow the visual and logical order of the form. If Tab jumps around unpredictably, that’s usually a sign of custom styling or a page builder overriding the natural DOM order.
• Focus states need to be visible. If someone can’t see which field is currently focused, they can’t navigate confidently. Removing the default focus outline without replacing it with a visible alternative is one of the most common accessibility mistakes I see on WordPress sites.
• Submit buttons should be reachable and activatable with Enter or Space, without requiring a mouse click.

How can you test form accessibility yourself?

You don’t need specialized tools to catch most of this. Unplug your mouse, and try filling out the form using only Tab, Shift+Tab, and Enter. If you get stuck, lost, or can’t tell which field you’re on, a visitor using assistive technology will hit the same wall, just with fewer ways around it.

Free tools like the WAVE browser extension or the Accessibility panel in Chrome DevTools catch most of the technical gaps (missing labels, contrast issues, ARIA errors) in under five minutes.

Accessibility work isn’t a separate project from good form design. Most of what makes a form accessible also makes it clearer and easier to use for everyone.