How to Label Form Fields for Accessibility

Understand the three parts of a usable form field

Forms often fail because several different jobs are compressed into one line of text. Separate the field’s accessible name, visible label, and supporting description.

A field labeled “Email address” has a clear purpose. The instruction “We will send the receipt here” explains why the information is requested. An error such as “Enter an address in the format name@example.com” explains how to correct the value. When these parts are coded distinctly, browsers and assistive technology can present them at the right time.

Why explicit labels improve more than screen reader output

A properly associated label lets a screen reader announce the control’s purpose. It also increases the clickable or tappable area for checkboxes and radio buttons, helps speech-input users refer to controls by visible words, and lets people return to a completed field without relying on placeholder text that has disappeared.

Four WCAG requirements work together

Accessible labeling is not covered by one rule alone. Success Criterion 3.3.2 requires labels or instructions when content requires user input. This applies to required and optional fields; “requires” means that the content accepts or expects input, not that only mandatory fields need labels.

Success Criterion 1.3.1 covers programmatic relationships, including the association between a visible label and its field. Success Criterion 2.4.6 requires headings and labels to describe topic or purpose. Success Criterion 4.1.2 requires a programmatically determinable name and role for user interface components, along with applicable states and values.

Prefer an explicit HTML label

For text inputs, textareas, selects, checkboxes, and radio buttons, the most dependable pattern is a label whose for attribute exactly matches the field’s unique id. The field’s name attribute performs a different submission-related job and does not create this association.

<p>Email address</p>
<input type="email"
       name="email">

<label for="email">
  Email address
</label>
<input type="email"
       id="email"
       name="email">

Visual proximity alone does not create a programmatic relationship. A label can also wrap its control to create an implicit association, but explicit matching is easier to inspect and often more resilient in component layouts.

Do not use placeholder text as the only label

A placeholder is a short hint displayed inside an empty field. It commonly disappears when the user types, can be mistaken for a prefilled value, and may provide insufficient contrast. It also makes error recovery harder because the field’s purpose is no longer visible while reviewing the entered value.

Keep the visible label outside the field. Use placeholder text only for optional, nonessential examples when its disappearance will not remove information. If the format matters, present it as persistent help text and associate it with the input.

Use aria-label and aria-labelledby deliberately

aria-label supplies an invisible string as the accessible name. It can be appropriate for a compact control whose purpose is visually clear from context, such as a search input next to a clearly labeled Search button. It should not become a shortcut for removing useful visible labels from ordinary forms.

aria-labelledby builds the accessible name from one or more existing elements. It is useful when the correct name is already visible elsewhere or when several text fragments must be combined. Ensure referenced IDs exist and remain unique.

When a control has a visible label, its accessible name should contain that visible wording. WCAG 2.5.3, Label in Name, supports predictable speech-input interaction: users should be able to say the words they can see.

Keep labels concise and instructions available

A label identifies the field. Instructions explain constraints or formats. Putting a long password policy inside the label can make repeated screen reader announcements tiring, while hiding the policy in a tooltip can make it hard to discover.

<label for="dob">Date of birth</label>
<input id="dob"
       placeholder="MM/DD/YYYY">

<label for="dob">Date of birth</label>
<span id="dob-format">
  Format: MM/DD/YYYY
</span>
<input id="dob"
       aria-describedby="dob-format">

aria-describedby associates supplementary information with a field. It does not replace the accessible name. Use it for format notes, constraints, privacy explanations, and error messages where appropriate. Keep essential instructions visible and close to the relevant control or group.

Group radio buttons and checkboxes with fieldset and legend

Individual options need individual labels, but users also need the shared question. The fieldset element groups related controls, and its legend identifies the group.

<fieldset>
  <legend>Choose a delivery speed</legend>
  <input type="radio" id="standard" name="speed">
  <label for="standard">Standard — 3 to 5 days</label>
  <input type="radio" id="express" name="speed">
  <label for="express">Express — 2 days</label>
</fieldset>

Do not repeat the whole question in every option label unless the surrounding technology requires a different pattern. A concise legend plus distinct option labels communicates both levels of meaning.

Give buttons action-oriented names

Native button content normally supplies its accessible name. Input buttons use their value. Image buttons use meaningful alt text. Prefer visible text such as “Save profile,” “Search articles,” or “Add billing address” over vague labels such as “Submit,” “Go,” or an unexplained icon.

If an icon-only button is truly necessary, give it an accessible name and make its visual meaning understandable. The same magnifying-glass icon may mean “Search” in one context and “Zoom image” in another. The name must describe the actual action.

Identify required fields without relying on color or an asterisk alone

Tell users whether fields are required or optional before they begin. If most fields are required, label the few optional fields; if only a few are required, mark those clearly. Explain any symbol at the beginning of the form and ensure the requirement is programmatically available through native required or an appropriate equivalent.

A red label alone is not enough because color cannot be the only means of conveying information. An unexplained asterisk may also be ambiguous. Visible text such as “Email address (required)” is direct. Do not add the word “required” to every accessible name redundantly if the browser and assistive technology already communicate the native required state; test the final experience for clarity.

Connect validation messages to the field and the correction

When an error is automatically detected, identify the affected item and describe the problem in text. Do not clear the user’s other valid answers. Move focus or provide an error summary when appropriate, and include links that take users to the fields needing attention.

Use aria-invalid="true" when validation establishes that a field is invalid. Add the error message to the field’s description, commonly with aria-describedby, while preserving any existing help text. Announce newly inserted feedback with an appropriate live-region or focus strategy, but avoid repeated or disruptive announcements.

Audit forms on the published WordPress page

Form markup may come from a theme, an embedded service, a custom HTML block, a checkout system, or a reusable pattern. The editor does not always show the final IDs, accessible names, hidden text, validation states, or duplicate forms. Inspect the delivered page.

1. Inventory every control.Include search fields, newsletter forms, comments, login fields, filters, checkout steps, and modal dialogs.
2. Find each accessible name.Check explicit labels first, then other naming mechanisms and button text.
3. Match visible and programmatic wording.Confirm that the accessible name contains the visible label used by speech-input users.
4. Check unique IDs.Repeated blocks and header-footer forms often create duplicate identifiers.
5. Review instructions and groups.Verify formats, constraints, required status, legends, and option labels.
6. Trigger every validation path.Submit empty, malformed, and conflicting values; inspect messages, focus, association, and retained data.
7. Test keyboard and assistive technology.Click labels, tab through controls, review the form-control list, and try speech commands where available.

Paste a form’s HTML into the DOFIW Form Label Checker to identify missing or mismatched labels and naming patterns before contextual review.

What the Form Label Checker can—and cannot—verify

The checker can analyze supplied HTML for labelable controls, explicit for-to-id relationships, common accessible-name attributes, empty labels, duplicate IDs, and related structural warnings. Processing occurs locally in the browser; the supplied HTML is not uploaded to a server.

JavaScript-generated controls may not appear in copied source markup, and an embedded cross-origin form may be inaccessible to a page-level checker. Always test the live rendered form. A clean automated report is not a WCAG certification.

Common labeling mistakes and direct fixes

• Nearby text without association: connect a real label to the field’s unique ID.
• Placeholder-only label: add a persistent visible label and move format guidance to help text.
• Mismatched for and id: make the values identical, including case, and ensure the ID is unique.
• Generic label: replace “Enter value” with wording that describes the expected information.
• aria-label replacing useful text: retain a visible label and let it supply the accessible name.
• Visible text absent from the name: include the visible words so speech commands remain predictable.
• Ungrouped radio options: add a fieldset, legend, and a separate label for every option.
• Instructions hidden after focus: keep essential formats and constraints persistently available.
• Required status conveyed by red alone: add text or an explained symbol plus a programmatic state.
• Error shown only as a border: identify the field and describe the correction in text.
• Repeated IDs in reusable blocks: generate or assign unique identifiers on the complete page.
• Testing only the initial form: review loading, validation, success, disabled, and multi-step states.

Accessible form label checklist

Continue the DOFIW form-content workflow

Frequently asked questions