Associate Every Form Control with a Label

This check finds form controls that do not have an accessible label. A placeholder, nearby text, or visual icon does not automatically create a reliable label.

Why this matters

People using screen readers need a programmatic name for each field, while speech-input users rely on visible text that matches that name. Labels also keep the instruction available after a user starts typing, unlike placeholders.

How to fix it

1. Use a visible <label> whose for value matches the control’s unique id.
2. Alternatively, wrap a simple input inside its label when that pattern fits the component.
3. Use aria-labelledby only when existing visible text must provide the name; use aria-label when no visible label is practical.
4. Keep help text and validation messages separate with aria-describedby.

When the finding appears across many URLs, fix the shared component or layout that produces it instead of patching generated HTML page by page. Recheck representative templates and responsive states after deployment so the correction does not create a regression elsewhere.

How to verify the fix

Inspect the accessibility tree and confirm that every input, select, and textarea has the expected accessible name. Click each visible label to ensure it focuses the correct control, then complete the form using only the keyboard.

Keep before-and-after evidence for the affected URL, original output, correction, and verification method. If markup changes after load, test consent states, localization, responsive variants, and client-side navigation because the initial HTML and rendered DOM can differ.

Further reading

• W3C form label tutorial