Accessible Forms and Labels

Associate each form control with a meaningful label so its purpose is available to all users, including people using assistive technology. Semantic HTML provides a reliable way to expose these relationships.

A form control should have a visible, meaningful label that describes what information the user should provide. The HTML `<label>` element is the standard way to associate a label with an `<input>`, `<select>`, or `<textarea>`.

The most common explicit association uses a label's `for` attribute and a control's matching `id`. For example, `<label for="email">Email</label>` paired with `<input id="email" type="email">` creates a programmatic relationship that browsers and assistive technologies can expose.

A label can also wrap its control, creating an implicit association: `<label>Email <input type="email"></label>`. Explicit labeling is often preferred because the relationship is easy to inspect and maintain, especially in larger forms.

Labels should describe the control's purpose rather than merely provide generic instructions. Placeholder text is not a substitute for a label because it can disappear during input and does not provide the same persistent semantic relationship.

Additional instructions or error information can be connected with mechanisms such as `aria-describedby` when appropriate. ARIA can supplement native HTML semantics, but it should not replace a native `<label>` when a label element can provide the required relationship.

Key points

• Use a meaningful `<label>` for form controls.
• For explicit labeling, match `<label for>` with the control's `id`.
• Keep labels available as persistent descriptions rather than relying on placeholders.
• Use `aria-describedby` for supplementary help or error text when needed.
• Prefer native HTML semantics before adding ARIA.

Interview questions

When would you use `aria-describedby` with a labeled form control?

Use `aria-describedby` when a control needs supplementary text beyond its primary label. For example, a password field might have a label such as `Password` and descriptive text explaining its requirements. The control can reference that text by its `id` through `aria-describedby`. This preserves the label as the primary identification while exposing additional context to assistive technology.

Why should form inputs have labels?

A label tells users what information a form control expects. A properly associated label also gives assistive technologies a programmatic name for the control. Clicking a label can activate or focus its associated control. This makes forms easier to understand and operate.

How do you explicitly associate a `<label>` with an `<input>`?

Give the input a unique `id`, then set the label's `for` attribute to exactly that value. For example, `<label for="name">Name</label>` pairs with `<input id="name">`. This creates a browser-recognized relationship between the two elements.

What is the difference between a label and a placeholder?

A label identifies the purpose of a control and remains available as part of the form's structure. A placeholder is hint text that appears inside an input and normally disappears when the user enters a value. Placeholder text can therefore be insufficient as the sole identification of a field. A robust form uses a real label and may use a placeholder only as supplementary guidance.

What would you check when reviewing a form for accessible labeling?

I would verify that every user-facing form control has an appropriate accessible name and that visible labels are meaningfully associated with their controls. I would inspect explicit `for` and `id` relationships and check that IDs are unique. I would also verify that supplemental instructions and errors are exposed appropriately without using ARIA to duplicate or replace native semantics unnecessarily. Finally, I would test keyboard interaction and, where practical, the form with assistive technology.