In an HTML form, what are the two ways to associate a <label> element with an input, and what does that association actually give the user?

## What "association" means Putting text beside a form field makes it look labelled. It does not make it labelled. A visual arrangement is invisible to the accessibility tree, to the browser's click-forwarding logic, and to anything that reorders the page. Association is a relationship expressed in the markup between a `<label>` element and one *labelable* control, and HTML gives you two ways to express it. ## Explicit association: for + id ```html <label for="email">Email address</label> <input type="email" id="email" name="email"> ``` The `for` attribute holds the **id** of the control. Two things people get wrong here: they point `for` at the `name` attribute, and they assume any id will do. `name` is what the form submits under; `id` is the document-unique handle `for` resolves against. Those two attributes frequently hold the same string, which is exactly why the mistake survives — it works until the day they differ. The explicit form is the one to reach for when the label and the field are separated in the markup by wrappers, error text, or a grid cell, because it does not constrain where either element sits. ## Implicit association: wrapping ```html <label> Email address <input type="email" name="email"> </label> ``` A `<label>` with no `for` attribute labels its **first labelable descendant**. No ids are involved, so nothing can drift out of sync and nothing has to be made unique. That property matters a lot in repeated markup — rows in a table, items rendered from a list — where handing every row the same id is a very common defect. The cost is structural: the control must live inside the label element. If your markup or your styling needs the text and the field in separate containers, use the explicit form instead. You may see both used at once (`<label for="x">…<input id="x"></label>`). That is legal as long as `for` points at the wrapped control itself; pointing it at a *different* control while wrapping one is a genuine conflict and should be avoided. ## What the association buys you **An accessible name.** The label's text becomes the control's name in the accessibility tree. A screen reader user hears "Email address, edit text" rather than "edit text", and voice-control users can say "click Email address". An unlabelled input is announced by its role alone, which tells the user nothing about what to type. **Click forwarding.** Clicking or tapping an associated label activates the control: text and number fields take focus, checkboxes and radios toggle, selects open. This is why a properly labelled checkbox has a hit target the size of its label text instead of a 13-pixel box — an accessibility win that also measurably helps everyone on a phone. **Durability.** Because the relationship lives in the markup, it does not break when CSS moves the label above, beside, or visually away from the field. ## What breaks it - `for` referencing an id that does not exist, or that belongs to a `<div>` or `<span>`. There is no association; the label is inert text. - Duplicate ids in the document. `for` resolves to the first match in tree order, so later fields end up unnamed and their labels focus the wrong control. - Trying to label two controls with one label. `for` takes a single id, and a wrapping label binds only its first labelable descendant. "Name" above a first-name and last-name pair needs two labels — or a `<fieldset>` with a `<legend>` when the shared text is really a group heading. - Using a non-labelable element. A `<div role="textbox">` is not labelled by a `<label>`; only `input` (other than `type="hidden"`), `select`, `textarea`, `button`, `output`, `meter`, and `progress` participate. ## The habit to build Write the label first, then the control. Every control that a user types into or chooses from gets one. If a design has no room for visible label text, that is a design conversation, not a licence to ship an unnamed field — the label element can still be present and positioned off-screen, and the field keeps its name, its click target, and its meaning.