In HTML and ARIA, what is an element's accessible name, and what does the browser compute it from for `<button>Save</button>` and `<img src="logo.png" alt="Acme home">`?

## What an accessible name actually is Every element exposed to assistive technology sits in the **accessibility tree** — a parallel tree the browser builds from the DOM, where each node carries a small set of properties: a **role** (what kind of thing it is), a **name** (which one it is), sometimes a **value** and a **state**, and optionally a **description**. The accessible name is the identity string. A screen reader typically announces name plus role — "Save, button", "Search, edit text", "Acme home, link". Voice-control software matches spoken commands against the same string: "click Save" works because the button's accessible name is "Save". Automated tooling uses it too — queries like `getByRole('button', { name: 'Save' })` in Testing Library and Playwright match on the computed accessible name, not on the raw markup. The key word is **computed**. There is no single `name` attribute in HTML. The browser follows the accessible name computation, a specified algorithm shared by HTML and ARIA, and walks a list of candidate sources in order until one produces a non-empty string. ## Where the name comes from, element by element Each element type has its own native source, defined by the HTML Accessibility API Mappings: ```html <button>Save</button> <!-- name: "Save" (text content) --> <a href="/help">Help centre</a> <!-- name: "Help centre" (text content) --> <img src="logo.png" alt="Acme home"> <!-- name: "Acme home" (alt) --> <label for="q">Search</label> <input id="q" type="search"> <!-- name: "Search" (associated label) --> <table><caption>Q3 revenue</caption>…</table> <!-- name: "Q3 revenue" (caption) --> <fieldset><legend>Shipping</legend>…</fieldset> <!-- name: "Shipping" (legend) --> <figure><img …><figcaption>Fig 1</figcaption></figure> <!-- name: "Fig 1" (figcaption) --> ``` Notice the pattern: elements whose visible content *is* the label (buttons, links, headings) take their name from their **subtree text**, while elements whose content is not a label (images, tables, groups, form fields) take it from a dedicated attribute or a companion element. This is the practical reason to reach for the right native element. `<button>Save</button>` gets a role, keyboard activation, focusability and a name from one element with no extra attributes. A `<div>` with a click handler gets none of them and must have all four reproduced by hand. ## alt="" is a deliberate empty name `<img alt="">` is not a missing alt. An empty `alt` tells the browser the image carries no information the user needs, and the image is removed from the accessibility tree entirely — a screen reader passes over it silently. That is the correct markup for a decorative divider or a background flourish. Omitting `alt` altogether is a different thing: with no `alt` there is no name source, so assistive technology may fall back to announcing the file name from `src`, which is why users hear "logo dot png, image". Every `<img>` needs an `alt` attribute; the judgement is only whether its value is empty or descriptive. ## Controls with no name The common failure is an interactive control that computes to an empty name: ```html <button><svg viewBox="0 0 16 16"><path d="…"/></svg></button> ``` The subtree contains an SVG with no text, so the computed name is empty and the control is announced as just "button". The user can reach it and press it but cannot tell what it does, and a voice-control user has no phrase to say. The same happens with an input whose only visible hint is a `placeholder`, since `placeholder` is at best a last-resort fallback and disappears the moment the user types. ## How to check it Do not guess from the markup — read the computed value. Chrome DevTools shows it in the **Accessibility** pane of the Elements panel, including which source produced it; Firefox has an Accessibility Inspector that shows the same tree. Automated scanners such as axe report controls whose accessible name is empty as a violation, and a `getByRole(…, { name })` query in a test suite fails loudly when a refactor silently strips the name. The habit worth forming is to treat the accessible name as a real, inspectable output of your markup, the same way you treat computed styles — something you verify rather than assume.