In HTML, what is the difference between aria-label, aria-labelledby, and aria-describedby, and when do you reach for each?

## Name and description are two different slots Every element exposed to assistive technology carries a **role** (what kind of thing it is), an **accessible name** (what it is called) and an **accessible description** (extra information about it). A screen reader typically announces name and role together — "Search, button" — and then, after a short pause or on request, the description. Voice-control software matches a spoken command against the *name*, not the description. Automated test tools and browser accessibility inspectors show both fields. That two-slot model is the whole answer. `aria-label` and `aria-labelledby` write into the name slot; `aria-describedby` writes into the description slot. Confusing the two is the most common mistake: a control whose only text lives in `aria-describedby` has no name at all and is announced as a bare "button". ## aria-label — a literal string ```html <button type="button" aria-label="Close dialog"> <svg aria-hidden="true" focusable="false"><!-- ✕ glyph --></svg> </button> ``` The attribute value *is* the name. Nothing on screen changes; only assistive technology sees it. Reach for it when there is genuinely no visible text to reference — icon-only controls, or a landmark that needs disambiguating (`<nav aria-label="Breadcrumb">`). Its weaknesses follow from being invisible. Nobody reviewing the UI sees it, so it rots when the icon's meaning changes. It is an attribute value, so localisation and translation workflows that only walk visible text can miss it. And it is ignored where the element has no meaningful role: ARIA marks `aria-label` prohibited on roles such as `generic`, which is what a plain `<div>` or `<span>` maps to, so labelling a wrapper `<div>` usually does nothing. ## aria-labelledby — point at text that already exists ```html <h2 id="billing-heading">Billing address</h2> <section aria-labelledby="billing-heading">…</section> ``` The value is a space-separated list of `id` values in the same document. The browser gathers the text content of each referenced element and joins the pieces in the order the IDs are listed. Because the name is derived from what is on screen, it stays in sync with the visible UI and gets translated along with the page. This is the right tool whenever the label is visible: a modal named by its title, a group of radio buttons named by a heading, a table of "Edit" buttons where each one is named by both its own text and the row's item name. ## aria-describedby — supplementary information ```html <label for="pw">Password</label> <input id="pw" type="password" aria-describedby="pw-hint"> <p id="pw-hint">At least 12 characters, including a number.</p> ``` Same ID-reference mechanism, different slot. The input's name is "Password" (from the `<label>`); the hint becomes the description. Screen readers read the description after the name and role, and some verbosity settings shorten or skip descriptions entirely — which is exactly why anything essential to identifying the control belongs in the name instead. Typical uses: input format hints, password rules, a note that a link opens a file of a given size, and the error text bound to an invalid field. ## Precedence, in one line When more than one is present, `aria-labelledby` wins over `aria-label`, and either overrides the name the element would otherwise get from its own content or its associated `<label>`. That is a sharp edge: adding `aria-label` to a button that already reads "Save changes" *replaces* the visible text for screen-reader and voice users rather than adding to it. ## Native markup comes first None of these three is the default answer. A form control paired with `<label for="…">` already has a name, and the label gives sighted mouse users a bigger click target that ARIA cannot provide. A `<button>Delete</button>` names itself. An `<img>` names itself through `alt`. Use the ARIA attributes to fill gaps native HTML cannot — not to re-do work the element already does. ## Choosing, in practice - Visible text exists and is correct → let it name the element, or reference it with `aria-labelledby`. - No visible text at all → `aria-label`. - Extra detail that is helpful but not identifying → `aria-describedby`. - Only a tooltip available → `title` is the last resort: it appears on hover but not reliably on keyboard focus, is unavailable on touch, and is easy for users to never see.