A cart page renders one row per item, and each row contains <label for="qty">Quantity</label><input id="qty">. What breaks, and how would you fix the labelling?

## The rule being broken An `id` must be unique within the document. `for` performs a lookup by id and takes the **first** match in tree order — there is no scoping to the nearest row, no error, no console warning. So in a list of nine cart rows all using `id="qty"`: - All nine labels associate with row one's input. - Clicking row seven's "Quantity" text focuses row one's box — a visible bug that testers usually catch eventually. - Rows two through nine have **no** associated label. Their inputs are announced by role alone: "edit text", nine times. This is one of the most common labelling defects in real applications, because it appears the moment static markup is turned into a loop, and the single-row case that was hand-authored and reviewed was correct. ## Fix one: unique ids ```html <label for="qty-sku-4821">Quantity</label> <input id="qty-sku-4821" name="items[4821][qty]" type="number"> ``` Derive the suffix from something stable about the item — a SKU, a line-item identifier — rather than from the loop index. Index-based ids are correct at first render and become misleading when the list reorders or an item is removed, and if two independent components on the page both use `qty-0` you are back to a collision. Also remember the id must be unique across the *whole document*, not just the widget: a sidebar, a modal, and an embedded partial all share one id namespace. ## Fix two: wrap instead ```html <label> Quantity <input type="number" name="items[4821][qty]"> </label> ``` Implicit association binds the label to its first labelable descendant. No ids, therefore no collisions, therefore nothing to keep unique as the list grows or reorders. For generated repeated markup this is usually the more robust choice, and its only real constraint is structural: the control must live inside the label element, which occasionally conflicts with a layout that needs them in separate containers. ## The defect underneath the defect Suppose you fix the ids. Every input is now correctly labelled — and a screen-reader user pulling up a list of the page's form fields hears "Quantity, Quantity, Quantity, Quantity…" with nothing to tell them apart. Correct labelling is not the same as *useful* labelling: a name has to identify the control, and in repeated markup a name that is identical across every instance identifies nothing. The markup-level fix is to put the distinguishing text inside the label: ```html <label> Quantity <span class="visually-hidden">for Blue T-shirt, medium</span> <input type="number" name="items[4821][qty]"> </label> ``` The span is part of the label's text content, so it is part of the name, and the class positions it off-screen so the visible column still reads simply "Quantity". The same reasoning applies to any repeated control in a list: "Remove", "Edit", and "Select" buttons in a table of rows are the identical problem wearing different clothes. ## Why this ships Three reasons worth naming, because an interviewer is often probing your review instincts rather than the fix itself. Nothing throws — duplicate ids are recovered from silently. It looks correct visually, since every row shows the word "Quantity" beside a box. And it passes a one-row test fixture; the bug only exists at length two and above. So the review habit that catches it is specific: **whenever markup containing an `id` moves inside a loop, that id is a bug until it is made unique or removed.** That single rule catches this, catches the repeated-`for` variant, and catches the same defect in any other id-dependent association. ## What to say "Ids are document-unique, so `for` resolves to the first match — every label points at row one, and every row after the first is unlabelled. I'd wrap the input in its label so no ids are involved, and I'd also make each label distinguish its row, because nine controls named 'Quantity' are technically labelled and practically useless."