In ARIA, what is the difference between an element's accessible name and its accessible description, and which of the two does a `title` attribute supply when the element already has a name from another source?

## Two properties, not one When the browser builds an accessibility-tree node it computes several properties independently. Two of them are text: the **accessible name** and the **accessible description**. They are produced by two separate algorithms, exposed through separate platform accessibility APIs, and consumed differently by assistive technology. Treating them as interchangeable is the root of a whole family of bugs. ## What each one is for The **name** is identity. It is the string that distinguishes this control from the one next to it, and it is announced together with the role: "Email address, edit text". It should be short, stable, and match what the user sees. Without it, the control is announced as an anonymous "edit text" and is unusable. The **description** is supplement. It carries the extra sentence a sighted user would read under the field: format requirements, a warning, the current validation error. Assistive technology announces it **after** the name and role, usually after a short pause, and screen readers expose settings that shorten or suppress descriptions entirely. Verbosity settings, braille displays and speed-reading habits all mean the description may never reach the user. That asymmetry produces the single most useful rule here: **anything the user must have to operate the control belongs in the name; anything helpful but optional belongs in the description.** A password field whose only statement of "minimum twelve characters" lives in the description is acceptable; a delete button whose only indication of *which* record it deletes lives in the description is not. ## Separate sources The name computation walks `aria-labelledby`, then `aria-label`, then the element's native source — subtree text, `alt`, `<label>`, `<caption>`, `<legend>` — and finally the fallback tier. The description computation is much smaller. Its primary source is `aria-describedby`, which, like `aria-labelledby`, takes a space-separated list of IDs and gathers their text. If there is no `aria-describedby`, `title` can supply the description instead. ```html <label for="pw">Password</label> <input id="pw" type="password" aria-describedby="pw-help"> <p id="pw-help">At least 12 characters.</p> <!-- name: "Password" description: "At least 12 characters." --> ``` A screen reader focusing that field announces roughly "Password, edit text, protected — At least 12 characters." ## title's dual role `title` is the only attribute that can end up in either slot, and it does so by elimination: ```html <button title="Dismiss dialog">Save</button> <!-- name: "Save" (subtree text wins) → title demoted to description --> <button title="Dismiss dialog"><svg …/></button> <!-- no other source yields text → name: "Dismiss dialog", no description --> ``` The rule is simply that `title` is consulted last by the name computation, and whatever is left over is available to the description computation. This is worth internalising because it means a `title` you added as a tooltip changes role depending on markup you may not control — add visible text to a previously icon-only button and its `title` silently stops being the name. It is a poor source in both slots: `title` appears only on mouse hover, is unreachable by keyboard and touch users, and screen-reader support for announcing it is inconsistent. Use it knowing it is a fallback, never as the plan. ## Practical consequences **Do not duplicate.** If the same string is both name and description, users hear it twice. A common instance is `<button aria-label="Close" title="Close">` — the `aria-label` names it and the `title` describes it with identical text. **Do not overflow the name.** Cramming a full sentence of instructions into `aria-label` makes every announcement of that control long, including in the screen reader's element list where users navigate by name alone. Keep the name to the label, push the sentence to the description. **Descriptions are not guaranteed.** Because users can suppress them, an error message exposed only as a description may go unheard. Error text is usually referenced by `aria-describedby` *and* made visible on screen, so both audiences get it. **Verify, do not assume.** Chrome DevTools' Accessibility pane lists name and description as separate computed properties, so you can see at a glance which slot a `title` landed in rather than reasoning about it.