Accessible Form Design: Labels, Groups and Layout

Think about the forms on your site: a contact form, a patient intake form, a quote request, a donation page, a job application. Somebody designed each of them, even if that somebody was a form plugin’s default template. Small design choices made at that stage decide whether a person with low vision, a memory difficulty, a tremor or a screen reader can fill it in.

Accessible form design is mostly about clarity before anyone types a letter: every field has a label that stays visible, related fields are grouped, instructions come before the field rather than after a mistake, and the layout follows one clear path. This post covers those design decisions. What happens when someone gets a field wrong is a separate subject, covered in our post on form error messages that people notice.

Labels: visible, close and specific

The label is the single most important part of a form field. WCAG has two criteria that apply directly: 1.3.1 Info and Relationships (the label must be connected to its field in the code, so assistive technology knows they belong together) and 3.3.2 Labels or Instructions (people must be told what to enter).

In HTML, the connection is simple:

<label for="phone">Phone number</label>
<input id="phone" type="tel" autocomplete="tel">

With that in place, a screen reader says “Phone number, edit text” when the field gets focus, and clicking the words “Phone number” puts the cursor in the box, which gives people with shaky hands a bigger target.

Accessible form labels follow a few design rules:

• Put the label above the field for most forms. It is easy to scan, it works at any screen width and it survives zoom. Labels to the left work on wide screens but tend to drift away from their field.
• Keep labels short and literal. “Email address” beats “Where can we reach you?”
• Do not use the same label twice on one form. Two fields both called “Name” (one for the patient, one for the emergency contact) confuse anyone listening.
• Checkboxes and radio buttons get their label to the right, and the label should be clickable.

Why placeholder text is not a label

The gray text inside an empty box looks tidy, which is why so many themes use it instead of labels. It causes real problems:

• It disappears as soon as someone types, so anyone who loses their place has nothing to check against.
• It is usually light grey and fails the 4.5:1 contrast minimum for normal text in criterion 1.4.3.
• It can look like a value that has already been filled in, so people skip the field.
• Some screen reader and browser combinations do not announce it reliably.

Placeholders are fine for a short example (“e.g. 555-0123”) as long as there is a real label as well. “Floating labels” that start inside the box and move above it when you type are a compromise; they can work if the label stays readable and has enough contrast in both positions, but test them at large zoom before you commit.

Grouping related fields

When several fields answer one question, group them. A set of radio buttons for “Preferred contact method”, a date of birth split into month, day and year, or a block of checkboxes for “Services you are interested in” all need a group name.

<fieldset>
  <legend>Preferred contact method</legend>
  <input type="radio" id="cm-phone" name="contact" value="phone">
  <label for="cm-phone">Phone</label>
  <input type="radio" id="cm-email" name="contact" value="email">
  <label for="cm-email">Email</label>
</fieldset>

Without the fieldset and legend, a screen reader user hears “Phone, radio button, 1 of 2” and has to guess what the question was. With them, they hear the question first.

On longer forms, visual grouping matters too. Headings such as “About you”, “Your appointment” and “Insurance” break a long intake form into sections that people can find again. Use real heading elements so screen reader users can jump between them.

Instructions before the field, not after

If a field has rules, say so before someone types. “Password must be at least 12 characters.” “Upload a PDF or JPG, up to 5 MB.” “Use the name on your insurance card.” Put the hint between the label and the field, and connect it in the code so it is read along with the label:

<label for="member-id">Member ID</label>
<p id="member-id-hint">The 9-character code on the front of your card.</p>
<input id="member-id" aria-describedby="member-id-hint">

Avoid instructions that depend on seeing the layout, like “fill in the fields on the right” or “the green button”. Someone using a screen reader or a phone in portrait mode will not see it the way you do.

And avoid hiding essential help behind an icon with a hover tooltip. A tooltip that only appears on mouse hover is invisible to keyboard and touch users. If the information matters, show it as text.

Required and optional fields

People need to know which fields they can skip. There are a few reasonable ways to show it:

Whatever you show visually, also mark required fields in the code (the HTML required attribute or aria-required="true") so screen readers announce it. And do not use color alone; a red label means nothing to someone who cannot tell red from black.

The best fix is often to cut fields. Every field you remove is one less thing to label, explain and get wrong. Do you really need a fax number, a company name and a “How did you hear about us?” dropdown on a contact form?

Layout: the quiet half of accessible form design

• One column. Two fields side by side (“First name” and “Last name”) are fine, but a form that zigzags across columns is hard to follow with magnification and often has a confusing Tab order.
• Tab order matches visual order. Press Tab from the top. The cursor should go down the form in the order you read it. If it jumps, the code order and the visual order disagree.
• Big enough targets. Small radio buttons and checkboxes are hard to hit. Criterion 2.5.8, new in WCAG 2.2, sets a 24 by 24 CSS pixel minimum (spacing between small controls can also satisfy it), and a clickable label makes the whole line of text part of the target.
• Visible focus. The field that has focus should be obvious, with a clear outline or border change. Many themes remove the browser’s default outline and put nothing back.
• Field borders with contrast. Pale gray boxes on white make fields hard to find. Criterion 1.4.11 Non-text Contrast asks for 3:1 for the boundaries of controls people need to identify.
• Field width as a hint. A ZIP code box does not need to be as wide as a street address box. Matching width to expected length quietly helps people.

For long forms, splitting into steps can help, as long as each step has a clear heading and progress (“Step 2 of 4: Your appointment”). For the plugin setup, see how to split a long WordPress form into steps; from an accessibility point of view the rule is to keep earlier answers and never force people to retype them.

Buttons at the end

The submit button should say what it does: “Send message”, “Request appointment”, “Donate”. Avoid “Submit” when something more specific fits, and avoid a “Reset” button next to it; it is easy to press by accident and wipes everything. If the button is an image or icon, it still needs text that screen readers can read.

Checking your own forms

You can test accessible form design with a browser, a free scanner and a free screen reader:

1. Click each label. Does it put the cursor in the right field?
2. Type something in each field. Can you still tell what the field is for?
3. Tab through the form. Is the order logical and is focus always visible?
4. Zoom the browser to 200 percent. Do labels stay next to their fields?
5. Run a free checker such as WAVE and look for “missing form label” errors.
6. Listen with a screen reader to one group of radio buttons. Do you hear the question?

If your forms are built with a plugin, much of this depends on how the plugin outputs its markup and which options you choose. Our post on WordPress contact form accessibility looks at the common plugins, and the broader WordPress forms guide covers choosing and setting up forms in the first place. Forms on stores, especially checkout, come up again in our guide to making an online store accessible.

Frequently asked questions

Can I hide form labels if my design has no space for them?

You can hide a label visually with a screen-reader-only class, so assistive technology still reads it, but this should be the exception. Sighted users with memory or attention difficulties also rely on labels. A search box with a clear button next to it is a reasonable case; a ten-field form is not.

Is an asterisk enough to show a field is required?

It can be, if you explain what the asterisk means before the first field and the field is also marked as required in the code so screen readers announce it. Writing “(required)” in the label is clearer for everyone and avoids relying on a symbol that some people miss.

Are floating labels accessible?

They can be. The label must be a real label connected to the field, stay visible after the person types, and have enough contrast in both its resting and raised positions. Test them at 200 percent zoom and with a screen reader, because many theme versions shrink the label to a size that is hard to read.

Do I need fieldset and legend for every group of checkboxes?

Use them whenever the options answer a shared question, such as a set of radio buttons or a group of interest checkboxes. A single checkbox, like agreeing to terms, does not need a fieldset; its own label is enough. Without the group name, people hear each option without knowing what is being asked.

Forms like these are rarely built badly on purpose. Usually someone was in a hurry and kept the plugin’s template. Our accessible web forms page explains how we review and repair them, and for stores, the WooCommerce accessibility page covers cart and checkout forms. Both are part of our accessibility services for US businesses.

Next in this series: Accessible Error Messages on Website Forms