Forms are where accessibility problems hurt most: a visitor who can’t use your contact form can’t reach you at all. Forming Forms generates accessible markup by default, and there’s no way to switch it off.
What the plugin does for you
Real labels, properly associated. Every field renders a <label> with a for pointing at its input’s unique id. Clicking the label focuses the field, and screen readers announce the label when the field takes focus. There are no placeholder-only fields, which vanish the moment someone starts typing.
Grouped choices in a fieldset. Radio groups and multi-checkbox groups are wrapped in a <fieldset> with the field label as the <legend>, so assistive technology announces the question along with each option — not just “Option 1” with no context.
Help text linked to its field. Help text is rendered with an id and referenced from the input’s aria-describedby, so it’s read out as part of the field rather than being floating text nearby.
Required fields marked twice. Visually with an asterisk, and programmatically with required and aria-required="true". The asterisk is aria-hidden, so screen readers announce “required” once instead of reading a stray star.
The response is announced. The success or error message lands in a container with role="alert" and aria-live="polite", so a screen-reader user hears the outcome instead of having to go looking for it after submitting.
Errors are linked, marked and focused. Each error message is linked to its field with aria-describedby, and the field gets aria-invalid="true", so screen readers read the problem along with the label. When a submission has errors, focus moves to the first field with a problem. After a successful submission or a form-level error, focus moves to the response message. The form is marked aria-busy while sending.
Group help is linked too. Help text on radio and checkbox groups is linked to the <fieldset>, not just the first option.
Custom messages. Each field can have its own “required” and “not valid” message, so you can explain exactly what’s needed. See Validation.
The honeypot is hidden from people. It’s positioned off-screen, marked aria-hidden="true", and given tabindex="-1", so it never receives keyboard focus and is never announced. A honeypot that traps screen-reader users is worse than no honeypot at all.
No keyboard traps and no custom widgets. Fields are native HTML controls — real <input>, <select>, <textarea> elements — so keyboard behavior, autofill, mobile keyboards and browser accessibility features all work the way visitors expect.
What’s on you
Write labels that make sense on their own. “Name” and “Email” beat “Field 1”. A screen-reader user often hears the label with no visual context around it.
Don’t rely on placeholder text. It disappears when typing starts, is often too low-contrast to read, and isn’t a label. Keep the label; use the placeholder for a format example if you need one.
Say what a required field needs, not just that it’s required. “Email — we’ll only use it to reply” in help text does more work than an asterisk.
Check your contrast. Colors come from the block editor’s controls, so it’s entirely possible to set light-grey text on white. Aim for a 4.5:1 ratio on labels, inputs and help text, and check the error red against your background too.
Keep the visible focus ring. Some themes remove focus outlines. Without one, a keyboard user can’t tell where they are in a form:
.forming-field__input:focus-visible {
outline: 2px solid currentColor;
outline-offset: 2px;
}Don’t make the form the only way to reach you. An email address or phone number in your footer costs nothing and works when everything else fails.