Accessible Forms: Labels, Errors, and Help Text

Forms are where visitors become customers, so a form that fails for some users costs you enquiries. Accessible forms are also easier for everyone, including people on phones. A few core techniques solve most problems.

Always use visible labels

Every field needs a text label that is programmatically linked to the input, using the label element with a matching for attribute (or by wrapping the input). This lets screen readers announce what the field is and enlarges the clickable area.

Placeholder text is not a substitute. It disappears when typing, often has low contrast, and may not be announced reliably. Use it only for examples, if at all.

For sets of related options, like radio buttons or checkbox groups, use fieldset and legend to provide a shared question or heading.

Mark required fields clearly

Say which fields are required in text, such as "(required)," not just with a colored asterisk. Use the required attribute where appropriate. Keep forms short, since each extra field reduces completion. See how to design a contact form that gets filled in.

Use the right input types

Types like email, tel, and number bring up appropriate keyboards on phones and offer built-in checks. Add autocomplete attributes, such as name, email, and tel, so browsers can fill in details. WCAG 2.1 includes a requirement to identify the purpose of common input fields.

Write helpful error messages

When something goes wrong:

Say what the problem is, in plain words. "Enter an email address like name@example.com" is better than "Invalid input."
Say where it is. Identify the field in text, not just with a red border.
Move or announce focus. Send keyboard and screen reader users to the first error, or show an error summary at the top with links to each field.
Do not rely on color alone. Add an icon or text. See color contrast.
Preserve what they typed, so people do not need to start again.

Provide instructions before the field

Place hints, like password rules or date formats, near the label and connect them to the input with aria-describedby.

Support keyboard use

Users should be able to move through every field and submit with the keyboard, in a logical order, with a visible focus indicator. See keyboard navigation and focus.

Make buttons clear

Use descriptive button text such as "Send message" rather than "Submit." Make buttons large enough to tap. See touch target sizes.

Be careful with CAPTCHAs

Image puzzles can block users with visual or cognitive disabilities. Consider alternatives such as hidden honeypot fields or other behind-the-scenes checks, and always offer an accessible route.

Confirm success

After submission, show a clear confirmation message and consider moving focus to it so screen reader users are informed.

Test it

Complete your form using only a keyboard, then with a screen reader. Check it on a phone. See website accessibility basics for broader testing advice.

The bottom line

Visible labels, helpful errors, logical order, and keyboard support make forms work for everyone, and improve completion rates too.