In HTML, how does aria-labelledby resolve when its value lists several IDs, and what happens if one of those IDs does not exist on the page?

## The value is an ID-reference list ```html <span id="verb">Delete</span> <h3 id="row-7-title">Q3 budget review</h3> <button type="button" aria-labelledby="verb row-7-title">…</button> ``` `aria-labelledby` does not take text, a selector, a class, or a query. It takes IDs, whitespace-separated, resolved against the same document. That is the first thing to get right, because `aria-labelledby=".row-title"` and `aria-labelledby="#verb"` both look plausible and both resolve to nothing. ## Concatenation order is attribute order The browser walks the ID list left to right, computes the text of each referenced element, and joins the results with spaces. Attribute order wins over document order: if `row-7-title` appears earlier in the DOM but later in the list, the name still reads "Delete Q3 budget review". Reordering the attribute value is the supported way to change how the name reads. The text of each referenced element is computed recursively — a referenced `<h3>` containing a `<span>` yields the whole heading's text — but references are not chased transitively. If a referenced element itself carries `aria-labelledby`, that inner reference is not followed a second level down; the recursion is deliberately bounded so a chain of labels cannot loop. ## Missing IDs fail silently A reference that matches no element in the document contributes nothing and produces no diagnostic. This is the single most common way a label goes wrong in production: - someone renames an element's `id` and misses the reference, - a component renders the referencing element but conditionally omits the referenced one, - IDs are duplicated across a repeated row, so every button in the list references the *first* matching element and they all end up with the same name. That last one is worth stressing: `id` must be unique in the document, and duplicate IDs in a list rendering silently collapse ten distinct button names into one repeated name. When markup is generated per row, the IDs have to be generated per row too. If every reference in the list fails, the attribute contributes an empty name and the computation continues on to the next source — `aria-label`, a native `<label>`, element content — so the visible symptom is often not "no name" but "the old name reappeared", which sends people hunting in the wrong place. ## Self-reference is legal and useful ```html <button id="del-7" type="button" aria-labelledby="del-7 row-7-title">Delete</button> ``` Including the element's own ID pulls in its own content as one piece of the name. This is the standard pattern for lists of repeated actions: the button keeps its short visible word, and the name announced is the unambiguous "Delete Q3 budget review". It also avoids duplicating the row title as an invisible string that can drift out of sync with the visible one. ## Hidden references and other sharp edges Two more things bite in practice. First, `aria-labelledby` overrides everything else the element would be named by, including a properly associated `<label>` — so a form control with both is named by the reference, and the visible label becomes purely decorative from the accessibility tree's point of view. Second, the attribute names the element; it does not create the two-way association a native `<label for>` does. Clicking the referenced text does not focus the input, and the referenced element does not gain any behaviour. If you want the click target as well, use `<label for>` and skip the ARIA. ## How to verify Do not eyeball the attribute — read the computed result. Every major browser's accessibility inspector shows the element's Name field along with where each piece came from, which immediately reveals a reference that resolved to nothing. Pairing that check with an automated audit that flags nameless controls catches the silent-failure class of bug before it reaches users.