Accessible forms: labels, placeholders and error messages that work

Why labels matter

A label tells everyone what a field is for. Screen readers announce the label when the field gets focus, and voice-control users say the label to select a field. Click targets also get larger when a label is connected, because clicking the label focuses the field. This relates to WCAG 1.3.1 (Info and Relationships), 3.3.2 (Labels or Instructions) and 4.1.2 (Name, Role, Value).

Fix 1: connect a real label

<!-- Before: no label connected -->
<input type="email" placeholder="Email">

<!-- After -->
<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">

The for value must match the field's id. The autocomplete value helps browsers fill the field and meets WCAG 1.3.5 (Identify Input Purpose) for personal data fields.

Fix 2: do not rely on placeholders

Placeholder text disappears as soon as someone types, has weak contrast in most browsers and is not a reliable label. Keep a visible label above or beside the field, and use the placeholder only for an example.

Fix 3: group related fields

<fieldset>
  <legend>Delivery method</legend>
  <label><input type="radio" name="ship" value="standard"> Standard</label>
  <label><input type="radio" name="ship" value="express"> Express</label>
</fieldset>

Fix 4: mark required fields in text

A red asterisk alone does not help someone who cannot see color. Add the word "required" to the label, or say at the top that fields marked "(required)" must be completed.

Fix 5: write errors people can use

• Say what went wrong in words (WCAG 3.3.1): "Enter an email address like name@example.com", not just a red border.
• Suggest how to fix it (3.3.3).
• Put the message next to the field and link it with aria-describedby.
• Mark the field invalid with aria-invalid="true".
• Move focus to the first error or to a summary at the top that links to each problem.

<label for="email">Email address</label>
<input id="email" type="email" aria-invalid="true" aria-describedby="email-error">
<p id="email-error">Enter an email address like name@example.com.</p>

The anatomy of an accessible form field

An accessible field has several parts that work together. A visible label says what to enter. The label is connected to the field in the code, so clicking the label focuses the field and a screen reader announces it. Hints explain format or rules. If a mistake happens, an error message appears near the field, says what is wrong and how to fix it, and is linked to the field so assistive technology can read it. Required fields are marked in text.

<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email"
       aria-describedby="email-hint email-error" aria-invalid="true">
<p id="email-hint">We send your receipt here.</p>
<p id="email-error">Enter an email address like name@example.com.</p>

Use autocomplete to reduce effort

The autocomplete attribute tells the browser what kind of information a field wants, for example name, email, street address or credit card number. WCAG 2.1 requires it for fields that collect information about the user (1.3.5). It helps people with motor, memory and cognitive disabilities, and it helps everyone who is typing on a phone.

Errors people can use

1. Describe the problem in words, not only with a red border.
2. Place the message next to the field, and also summarize errors at the top for long forms.
3. Say how to fix it: "Enter a date in the format DD/MM/YYYY".
4. Move focus to the first error or the summary after a failed submit.
5. Keep what the user already typed.
6. Do not clear the form.

Select menus, radio buttons, checkboxes and date fields

Authentication and WCAG 2.2

WCAG 2.2 adds two criteria that affect forms. Redundant Entry (3.3.7) says you should not ask people to retype information they have already given in the same process, for example a shipping address repeated as a billing address. Accessible Authentication (3.3.8) says logging in should not depend only on remembering a password or solving a puzzle; allowing paste, password managers and email links satisfies it for many sites. See WCAG levels and versions.

Test your form in five minutes

1. Tab through the form. Does every field get focus in a sensible order?
2. Click each label. Does focus move to the field?
3. Submit the form empty. Do you get clear messages?
4. Fill it in wrongly in a different way each time. Are messages specific?
5. Zoom to 200 percent. Does everything stay usable?

Labels, instructions and hints: what goes where

Labels that match the visible text

Voice control users say the name of a field to move to it. If a field's visible label says "Postcode" but the code calls it "Zip", saying "Postcode" may not work. WCAG 2.5.3 Label in Name asks that the accessible name contains the visible label text. The easiest way to get this right is to use a real label element and not to override it with a different name.

Long forms and multi-step processes

• Show progress, such as "Step 2 of 4".
• Keep step titles as real headings.
• Do not clear information when someone goes back.
• Move focus to the top of each new step and announce the step.
• Let people review and change answers before submitting.
• Avoid time limits, or allow people to extend them.

Form mistakes to catch, by scan and by hand

A worked example: fixing a contact form

A contact form has three fields with placeholders "Name", "Email" and "Message", and a "Send" button. A scan flags all three fields as unlabeled. The fix is to add visible labels above each field and keep the placeholders as examples, such as "name@example.com". The form shows a red border on errors, so the developer adds text under each field, such as "Enter your email address", connects it to the field, and moves focus to the first error after submission. After the change, a keyboard user can complete the form, a screen reader announces each label and error, and a customer with low vision can see what to do. The whole change takes less than an hour.

Why this matters to your business

Forms are where visitors become customers: they sign up, check out, book and ask for help. A form that a visitor cannot complete costs a sale, and the cost is easy to miss because the visitor simply leaves. Accessible forms also tend to perform better for everyone, since clear labels, helpful errors and autofill reduce abandoned forms. Fixing forms is one of the highest-value things you can do for accessibility.

Groups, fieldsets and legends

When several fields answer one question, group them. A set of radio buttons for "Delivery method" belongs in a fieldset with a legend, so a screen reader announces the question before each option. The same applies to a group of checkboxes, to a date entered as day, month and year, and to a shipping address. Without a group, a screen reader user hears "Standard" and "Express" with no context.

<fieldset>
  <legend>Delivery method</legend>
  <label><input type="radio" name="delivery" value="standard"> Standard (3 to 5 days)</label>
  <label><input type="radio" name="delivery" value="express"> Express (next day)</label>
</fieldset>

Your questions about form labels

• Is it fine to hide a label visually? Only when another visible cue makes the purpose obvious, such as a search icon next to a field. Use a visually hidden label, not display:none, which hides it from assistive technology too.
• What about floating labels? They can work if the label remains visible and readable after the user starts typing and if the contrast is good. Test them at high zoom.
• Should I disable the submit button until the form is valid? It is usually better to keep it active and show clear errors on submit, because a disabled button gives no reason.
• How do I announce an error summary? Place it at the top of the form, give it a heading, move focus to it after a failed submit and link each item to its field.

A worked example: fixing a newsletter sign-up

A footer newsletter form has a single email field with the placeholder "Your email" and a button with an arrow icon. A scan reports that the field has no label and the button has no name. A visitor with a screen reader hears "edit text" and "button", with no clue what either does.

The fix has three small parts. Add a visible label, "Email address", above the field, and keep the placeholder as an example. Give the button the text "Subscribe" and keep the arrow as a decorative icon. After the form is submitted, show a confirmation message in text and announce it, so everyone knows it worked. The change takes about ten minutes and improves sign-ups for all visitors, because the purpose of the form is clear at a glance.

Notes for designers

• Design the error state and the focus state of every field, not only the empty state.
• Place labels above fields. They are easier to read at high zoom and on phones than labels to the side.
• Keep forms short. Ask only for what you need.
• Use the right input type, such as email, tel or number, so phones show the right keyboard.
• Group related fields visually and in the code.

Do not forget the less obvious fields

• Search boxes need a label, even if it is hidden visually and the button says "Search".
• Coupon and gift card fields need a label and a clear result message.
• Quantity fields need a label such as "Quantity of Blue mug".
• Consent checkboxes should have a label that is the actual statement, written in plain language.
• Hidden spam-trap fields must be hidden from assistive technology so that people do not fill them in by mistake.
• Dropdowns for country and state should be native selects, or tested custom controls.

Working with third-party form tools

Many sites use form builders, scheduling tools and payment forms from other companies. Before you choose one, open its demo and tab through it. Check that every field has a visible label, that error messages appear next to the field and that the form can be completed without a mouse. Ask the vendor for their accessibility information. If a tool fails, look for another, or offer a simple alternative such as an email address. Keep in mind that you remain responsible for what your visitors experience, even when a vendor supplies the form.

Quick reference

Checkout and sign-up forms

These forms decide whether you get the sale. Test the whole flow with a keyboard and a screen reader, including address fields, card fields embedded from a payment provider and the confirmation page. See the e-commerce accessibility checklist.