Most small business sites on WordPress have one form that matters: the contact form. It was probably set up years ago with whatever plugin the original developer liked, styled to match the theme, and never looked at again unless the emails stopped arriving. WordPress contact form accessibility tends to come up only when someone reports they could not use it, or when an audit lists the form near the top of the problems.
This post is a working checklist for the form you already have. It covers what Contact Form 7, Gravity Forms, WPForms and similar plugins usually handle for you, what they leave to your setup, and the few markup details worth checking by hand. It does not go into form design theory; for that, see our post on accessible form design.
What the plugin decides and what you decide
Every form plugin generates HTML. Some of it you can change from the form builder: field labels, descriptions, which fields are required, the wording of messages. Some of it is baked in: how the label is tied to the input, how errors are inserted, whether messages are announced. Then the theme adds its own styles on top, which can hide labels, remove focus outlines or shrink contrast.
So when a form fails, the fix can live in any of three places. Knowing which one saves a lot of time:
- Your form settings: missing labels, vague instructions, unclear required markers, poor message wording.
- The plugin: how errors and success messages are inserted into the page, how CAPTCHA or spam checks are added.
- The theme or custom CSS: invisible focus, placeholder-only styling, low contrast on fields and buttons.
If you are still choosing between plugins, our comparison of Contact Form 7 and WPForms covers the wider differences. The checks below apply whichever you use.
Plugin by plugin: where to look
Contact Form 7
Contact Form 7 builds forms from a text template you edit, using form tags for each field. That gives you a lot of control, which cuts both ways. An accessible Contact Form 7 setup depends on the template: each field tag should sit inside a label element, or be tied to one, with the label text written out. Templates that were edited to put labels in plain paragraphs, or that dropped labels and relied on placeholders, are a common finding. The fix is usually a template edit, not a new plugin.
Also check its response messages after sending. Read them with a screen reader to confirm they are announced, and make sure the wording is clear.
Gravity Forms
Gravity Forms builds fields through a visual editor and has worked on accessibility over several versions. Older forms on long-running sites sometimes use older markup than newly created ones, so a form built years ago may behave differently from one made last week. Check each form, not just the plugin. Pay attention to multi-page forms, date fields and any add-ons that insert their own fields.
WPForms and other drag-and-drop builders
WPForms and similar builders let you drag fields into place and set labels in a side panel. The trap here is the option to hide a label for a cleaner look. Find out whether that hides it only visually or removes it for screen readers too, by inspecting the field or listening to it. If in doubt, keep labels visible. The same applies to any builder bundled with a page builder or theme.
Whatever plugin you have, its marketing page is not proof of WordPress contact form accessibility. Test the form as it appears on your site.
Markup checks you can do in the browser
No coding is needed for these. Right-click a field, choose Inspect, and look at the highlighted code.
- Label connection. The label should either wrap the input or use a “for” attribute that matches the input’s “id”. Click the label text: if the cursor jumps into the field, they are connected.
- Required fields. A red asterisk alone is not enough for everyone. Look for the word “required” in the label or a note at the top of the form explaining the asterisk, plus the required attribute or aria-required on the input.
- Input types and autocomplete. Email and phone fields should use the email and tel types, and name, email and phone should have autocomplete values so browsers can fill them in.
- Groups. Sets of radio buttons or checkboxes, such as “How should we contact you?”, need a group label, usually a fieldset with a legend.
- Help text. If a field has instructions under it, they should be linked to the field (often with aria-describedby) so a screen reader reads them along with the label.
A free browser checker will flag some of these, especially missing labels. It will not tell you whether a label is useful, so read them yourself. “Name” is fine. “Field 3” is not.
Spam protection that does not lock people out
Contact forms attract spam, so most sites add something. Image puzzles and distorted text are the ones that shut people out. WCAG 3.3.8 Accessible Authentication (Minimum) is written for login steps rather than contact forms, but its reasoning carries over: puzzles and memory tests block real people. Invisible checks and honeypot fields usually cause fewer problems, as long as the hidden field cannot be reached by keyboard and is hidden from screen readers.
If you use a challenge, test it with a keyboard and a screen reader, and check that it has an alternative. We look at the options in more detail in accessible CAPTCHA alternatives.
Errors and the success message
Submit the form empty. What happens?
- Each error should name the field and say what to do: “Enter your email address”, not “This field is invalid”.
- Errors should not rely only on a red border.
- Focus should move to the first error, or to a summary at the top that links to each one, so a keyboard user is not left at the submit button wondering why nothing happened.
Now fill it in properly and submit. The success message is where many forms fail quietly. If it appears in place of the form, a screen reader user may hear nothing at all, because nothing they were focused on changed. WCAG 4.1.3 Status Messages covers this: the message should be announced without the person having to find it. Moving focus to the message also works.
Some sites send people to a separate thank-you page instead. That is often the most reliable option, because the new page title and heading are read out on arrival. Our guide to a form thank-you page in WordPress covers the setup.
A ten-minute WordPress contact form accessibility test
- Tab from the top of the page into the form. Is focus always visible on each field and the button?
- Fill it in with the keyboard only, including any dropdown, checkbox and consent box.
- Submit it empty and check the errors.
- Submit it correctly with a screen reader running and listen for the confirmation.
- Zoom to 200 percent and check that labels and fields still line up and nothing is cut off.
Then check the email notification still arrives, since template edits sometimes break the mail tags.
Forms are one stop in a longer customer path. On a store, that path runs from product search to order emails, and our accessible online store guide walks through each stage. For a broader view of audits and fixes, see our ADA website accessibility help, and for hands-on repair of labels, errors and plugin markup, our accessible form fixes page.
Frequently asked questions
Which WordPress form plugin is the most accessible?
There is no single answer, because the result depends on the version, your theme and how each form is set up. Several popular plugins have made accessibility improvements over the years. Build the same short form in the plugin you already use, test it with a keyboard and a screen reader, and switch only if you hit problems you cannot fix.
Can Contact Form 7 be made accessible?
Yes, in most cases. Because you write the form template yourself, you control the labels and much of the structure. Make sure every field has a label tied to it, mark required fields in text, and check that error and success messages are announced. Theme styles and any add-ons still need testing.
Does the hide label option in my form builder hurt accessibility?
It depends on how the builder hides it. Some keep the label in the code for screen readers and only hide it on screen; others remove it entirely. Inspect the field or listen to it with a screen reader. Even when screen readers still get it, sighted visitors lose the label, so keep labels visible on anything longer than a single obvious field.
How do I check if my form’s success message is announced?
Turn on a screen reader such as NVDA or VoiceOver, fill in the form and submit it without moving the mouse. Listen for the confirmation. If you hear nothing, or have to hunt around the page to find it, the message needs to be marked up as a status message or focus needs to move to it.
If your contact, quote and account forms sit inside a WooCommerce store, we check them as part of the whole store. Our page on WooCommerce store accessibility explains how that review and repair works.
Next in this series: Product Filter Accessibility for Online Stores
