Skip to main content
Accessibility Field Guide

Forms and Labels

A practical Field Guide page about labels, instructions, grouping, and required fields that help forms feel usable instead of like guessing games.

A notebook, clipboard, folders, and pens arranged on a desk.
Photo: Notebook and clipboard with papers placed on desk with folders and pens via Pexels — https://www.pexels.com/photo/notebook-and-clipboard-with-papers-placed-on-desk-with-folders-and-pens-5668469/
View full screen Download image

A form is not just a set of fields.

It is a conversation with the user.

The page asks for something. The user tries to answer. Labels, instructions, grouping, required-field cues, and error messages are what keep that conversation from turning into a guessing game.

When those pieces are missing or unclear, the form may still look finished. It may even pass a quick visual review. But for the person trying to complete the task, the path is shaky.

They may not know what a field means.

They may not know which fields are required.

They may not know what format the page expects.

They may not know whether two radio buttons belong to the same question or two different questions.

That is where form rework starts.

The common project moment

A team is building a request form, application, search screen, account update, payment flow, upload step, or eligibility questionnaire.

The wireframe has fields. The requirements name the data. The developer can build the inputs.

But no one has answered the smaller questions that make the form usable:

  • What does each field mean to the user?
  • What wording should appear as the visible label?
  • Which fields are required?
  • What format is expected?
  • Which fields belong together?
  • What instructions does the user need before they answer?
  • What happens if they answer wrong or leave something blank?

Those questions can feel minor during design and requirements. They are not minor for the person using the form.

What to notice earlier

Labels should identify the field

A visible label should make the field’s purpose clear without relying on placeholder text, nearby headings, or the user’s memory.

Placeholder text disappears when someone starts typing. It can be missed by assistive technology depending on implementation. It also asks the user to remember the instruction while they are entering the answer.

A better pattern is a persistent visible label with any extra help nearby.

Less helpful:

  • A blank field with placeholder text like Enter value
  • A group of inputs under a vague heading like Information
  • A field labeled only Type or Number when several kinds of type or number are possible

More helpful:

  • Email address
  • Case number
  • Date of birth
  • Preferred contact method
  • Upload proof of residency

Instructions should appear before the user needs them

If the user must follow a format, meet a file requirement, choose from a limited set of options, or provide specific evidence, say so before they make the mistake.

Examples:

  • Use MM/DD/YYYY.
  • Enter your 10-digit phone number.
  • Upload a PDF, JPG, or PNG under 10 MB.
  • Select all programs that apply.
  • Choose one contact method.

Instructions are not just nice copy. They prevent avoidable errors.

Required fields should be clear

If a field is required, the page should communicate that clearly.

Do not rely only on color. Do not rely only on an asterisk unless the asterisk is explained. Do not make users submit the form just to discover which fields mattered.

Useful patterns:

  • A short note near the top: Required fields are marked with an asterisk.
  • Visible required markers in the label.
  • Clear error messages if a required field is missed.

If most fields are required, it may be clearer to mark optional fields instead. The important thing is that the user does not have to guess.

Some form controls only make sense as a set. Radio buttons, checkboxes, address fields, date segments, and repeated sections often need a visible group label.

The group label answers the larger question.

The individual options answer that question.

For example:

  • Group label: Preferred contact method
    • Email
    • Phone
    • Mail
  • Group label: Documents you can provide
    • Driver’s license
    • Utility bill
    • Lease agreement

Without the group label, the options may be technically present but hard to understand out of context.

The accessible name should match the visible label

The text people see and the name assistive technology receives should line up.

If the visible label says Search by case number, but the accessible name is just Search, the experience can become confusing for someone using a screen reader or voice control.

This becomes especially important for repeated controls like:

  • multiple Edit buttons
  • multiple Remove buttons
  • multiple search fields
  • icons without visible text

A useful test question:

If someone heard only the control name, would they know what it does?

Questions teams can ask

During intake or requirements

  • What information does the user need to provide?
  • Which fields are required?
  • Are there format rules, file limits, or eligibility constraints?
  • Are any fields grouped into one larger question?
  • What labels and instructions need to be written before design or development?
  • Are any fields reused across screens or forms?

During design

  • Is every input paired with a visible label?
  • Are instructions close to the field they explain?
  • Are required fields identified clearly?
  • Are radio buttons and checkboxes grouped under a clear question?
  • Does the layout still make sense when zoomed or viewed on a narrow screen?

During development

  • Is each label programmatically associated with its input?
  • Do fieldsets, legends, headings, or ARIA labels support grouped controls where needed?
  • Does the accessible name match the visible label?
  • Are custom components preserving native form behavior?
  • Are instructions and errors connected to the fields they explain?

During QA

  • Can you tab through the form in a logical order?
  • Can you tell what each field is for without using a mouse?
  • Can you identify required fields before submitting?
  • Can you use the form at 200% zoom or on a narrow screen?
  • If you intentionally make a mistake, does the page help you recover?

Common trail hazards

  • Labels appear only as placeholder text.
  • Required fields are only shown by color.
  • Asterisks are used but never explained.
  • Radio buttons or checkboxes do not have a clear group question.
  • Error messages appear after submission but instructions were missing before submission.
  • The visible label and accessible name do not match.
  • Repeated buttons have generic names like Edit, Remove, or Select.
  • Custom inputs look like form controls but do not behave like native form controls.

Small habit

Before a form moves too far into build, read the form out loud as a conversation.

For each field, ask:

What is the page asking, what does the user need to know before answering, and how will the page help if the answer is missing or wrong?

If that conversation is unclear, the form probably needs better labels, instructions, grouping, or error support.

Use these as trail markers, not as the whole conversation:

What to do next

  • Check one real form or workflow and name any labels, instructions, groups, or required fields that are unclear.
  • If the form can fail, read Error Messages and Recovery next.
  • If required fields, errors, selected states, or disabled actions rely on color alone, check Color-Only Meaning.
  • If labels, helper text, placeholder text, error borders, or disabled-looking controls are hard to see, check Color Contrast.
  • If a form field uses autocomplete, suggestions, or a typeahead list, check Combobox.
  • If a form uses image buttons, icon-only actions, CAPTCHAs, or screenshot examples, check Alt Text Basics.
  • Use the Form Review Checklist before the form goes to review.
  • If the form is still being scoped, bring the findings into the Accessibility Requirements Checklist.