aria-label vs labelledby vs describedby

## Why the button starts out nameless The accessible name of a `<button>` normally comes from its own text content. An icon-only button has none — the `<svg>` inside it is graphics, and its `<path>` data is not text — so the accessibility tree exposes a control with a role and an empty name. Screen-reader users hear "button" with no idea what it does; voice-control users have nothing to say to activate it; automated audits flag it as a nameless interactive element. ## Option 1 — aria-label ```html <button type="button" aria-label="Delete message"> <svg aria-hidden="true" focusable="false" width="16" height="16">…</svg> </button> ``` One attribute, name solved. `aria-hidden="true"` on the icon removes it and its subtree from the accessibility tree so nothing stray leaks into the name; `focusable="false"` guards against older browsers putting inline SVG in the tab order. The drawback is that the string is invisible to everyone reviewing the UI. It is easy for the icon to change meaning while the label stays behind, and translation workflows that walk visible text can skip attribute values. ## Option 2 — visually hidden real text ```html <button type="button"> <svg aria-hidden="true" focusable="false">…</svg> <span class="visually-hidden">Delete message</span> </button> ``` The text is genuine content: it is in the DOM, it names the button through ordinary content-derived naming, and it flows through the same localisation path as the rest of the page. The catch is that the hiding technique matters. A class that uses `display: none` or `visibility: hidden` removes the text from the accessibility tree too, and you are back to a nameless button. The utility class has to keep the element rendered while clipping it out of view — that is why teams keep a single shared, tested "visually hidden" utility rather than improvising one per component. ## Option 3 — aria-labelledby ```html <h3 id="msg-42-subject">Q3 budget review</h3> <button type="button" aria-labelledby="del-label msg-42-subject"> <span id="del-label" hidden>Delete</span> <svg aria-hidden="true" focusable="false">…</svg> </button> ``` Worth it when the useful part of the name already exists on screen — most often in a list where a dozen identical icon buttons need to be told apart. Listing several IDs concatenates their text in the order given, producing "Delete Q3 budget review". ## What not to do `title="Delete"` alone is the tempting shortcut and the weakest option: the tooltip appears on mouse hover, generally not on keyboard focus, and not at all on touch, so most users never see it. It can serve as a fallback for the name when nothing better exists, but designing around it means designing for mouse users only. A bare `<div>` or `<span>` with a click handler is worse still: no name, no keyboard focus, no Enter/Space activation, no role. Start from `<button>` and the only thing left to solve is the name. Finally, do not describe the picture. The name should say what the control *does* — "Delete message" — not what the glyph looks like ("trash can icon"). And avoid stuffing the word "button" into the label; the role is already announced, so `aria-label="Delete button"` produces "Delete button, button". ## Getting the name right Write the name the way a user would refer to the action out loud, keep it short, and make it unique within its context — three buttons all named "Edit" in one list are technically named and practically useless. Then verify it: open the browser's accessibility inspector and read the computed Name field for the button rather than assuming the attribute took effect.