What makes a WordPress contact form accessible

The checklist

• A <label for> on every input, pointing at its id. Placeholder text is not a label: it disappears when you type.
• Required fields marked three ways — the required attribute, aria-required="true", and visible text such as “(required)”, not just a red asterisk.
• Help text linked with aria-describedby, so it's read when the field gets focus.
• Groups in a fieldset — radio buttons and checkboxes inside a <fieldset> with the question as its <legend>.
• Errors next to the field, linked with aria-describedby, and the field marked aria-invalid="true".
• An error summary at the top with a link to each problem field.
• A success message in a status region (role="status") so it's announced without moving focus.
• Autocomplete hints for name, email and phone, so browsers and assistive tools can fill them in.
• Spam traps invisible to assistive technology — a honeypot must be hidden with aria-hidden and taken out of the tab order.

How Mailbag's forms are built

Every item in that list is how Mailbag Contact Form draws its forms, whichever template you start from. Required fields show “(required)” after the label; after a failed submission without JavaScript, the page shows a summary with one link per error, and each field carries its own message. With JavaScript, errors are shown the same way without reloading, and the thank-you message is announced from a status region.

What you still control

• Write labels that make sense on their own: “Email address”, not “Enter here”.
• Check your theme's colours: input borders and error text need enough contrast against your background.
• Don't add a CAPTCHA you don't need. Visual puzzles are a barrier; Mailbag's honeypot, time trap and per-address limit work without any.