Associating a label with a form input

WHAT THIS TESTS This checks basic but essential accessibility knowledge: how the browser builds an accessible name for a form control and why a visually present caption is not enough if it is not programmatically linked.

A GOOD ANSWER COVERS There are two valid native patterns. Explicit association uses a label element with a for attribute whose value equals the input id attribute; the browser links them. Implicit association wraps the input directly inside the label element, so no id is needed. Both make the label text the accessible name of the control, which screen readers announce when the field gains focus, and both make clicking the label focus or toggle the input, enlarging the hit target, which helps motor-impaired and touch users. If a visible label is impossible, aria-label or aria-labelledby can supply the name, but a real label is preferred when text is visible.

COMMON WRONG ANSWERS Using placeholder text as the label is the classic mistake; placeholders disappear on input, often have poor contrast, and are inconsistently announced. Putting caption text in a nearby span or div without any association leaves the input nameless to assistive technology. Reusing the same id for multiple inputs breaks the for linkage.

LIKELY FOLLOW-UPS When would you use aria-labelledby instead? How do you label a group of radios? What about required fields and error messages, which use aria-describedby and aria-invalid? How does the accessible name computation order resolve conflicts?

ONE CONCRETE EXAMPLE A search box with only a magnifying glass placeholder is announced as edit text with no name, leaving a screen reader user guessing. Adding a label with for pointing to the input id, visually hidden if design demands, makes it announce as Search edit text, and now tapping the label focuses the box.