Accessible Forms: Labels, Errors and Focus

Forms are where websites do their most important work. People sign up for memberships, register for events, make donations, buy products and ask for help through forms. A confusing form loses people at exactly the moment they wanted to act.

Accessible forms work better for everyone, including people who use screen readers, people who navigate by keyboard and people filling in a form on a small phone in a hurry. Here are the practices we follow.

Every field has a real label

Each field needs a visible label that says what belongs in it, connected to the field in the page's code so assistive technology can announce it. Placeholder text inside an empty field is not a label: it disappears as soon as someone types and often has low contrast.

Our admin forms use labeled fields grouped into sections with headings, as required by our admin design standard. Public forms built with our forms module do the same.

Instructions come before they are needed

If a field has a requirement, such as a password length or a date format, say so before someone types, not only after they get it wrong. Helper text under a field is ideal. It should be connected to the field so screen readers announce it too.

Errors that explain and point

When something is wrong, people need to know what and where. Good error messages:

1. Appear next to the field with the problem, not only in a summary at the top
2. Say what is wrong and how to fix it, in plain words
3. Are announced to screen reader users when they appear
4. Move focus to the first problem, or provide a summary with links to each field
5. Keep everything the person already typed

That last point deserves emphasis. Clearing a long form because one field was wrong is one of the most discouraging experiences on the web.

Do not rely on color alone

Marking an error only by turning a border red leaves out people who cannot distinguish colors. Errors should also include text and, where useful, an icon. The same applies to required fields: mark them with text or a symbol explained on the page, not only with color.

Keyboard and focus

Every field, checkbox, radio button and button must be reachable by keyboard in a logical order, with a visible focus indicator. Custom controls, such as styled dropdowns and toggles, must behave like the native controls they replace. You can read more in keyboard focus is a feature.

Safe submission

A form should submit once, even if someone presses the button twice, and should show that it is working. Interactive forms that update without reloading the page must still prevent the browser's default submission when they handle it themselves; otherwise the page can reload unexpectedly and lose the person's work. We learned that detail while building our in-app help chat, whose form now prevents native submission explicitly.

Ask only for what you need

Every extra field is a reason to give up. We ask for the information a task requires and explain why when it is not obvious. Optional fields are clearly marked. Sensitive information, like card numbers, is handled by specialized fields from the payment processor and never by our own form fields, as explained in why card numbers never touch our servers.

Consent is explicit

Forms that add someone to a mailing list or a text message list should ask for that permission explicitly, rather than assuming it from a purchase or registration. A consent checkbox should start unchecked, and its wording should say exactly what the person is agreeing to. We treat consent as its own decision, which we explain in consent first.

Test with real tools

We test forms with a keyboard, with a screen reader where possible, at phone width and with intentional mistakes. Submitting a form with every field wrong is a quick way to see whether the error experience is helpful or hostile.

Frequently asked questions

Is placeholder text enough as a form label?

No. Placeholders disappear when typing begins and are often hard to read. Every field should have a visible label connected to it.

How should form errors be shown?

Next to the field with the problem, in plain words that explain how to fix it, announced to screen readers and without clearing what was already entered.

Why do some forms lose what I typed?

Usually because the page reloads on submission. Well-built forms keep entered values when showing errors and prevent unexpected reloads.