Why is the title attribute on an img element not a substitute for its alt attribute?

## Two attributes, two jobs `alt` and `title` are both text you attach to an `<img>`, which is why they get confused, but the specification gives them different jobs. - `alt` is the **text alternative**: the substitute content for the image. It is what a browser paints in the image's box when the file fails to load, and it is what names the image in the accessibility tree. - `title` is **advisory information**: an aside. "This chart was recorded on a Tuesday." Nothing in the page's meaning may depend on it. ```html <!-- alt carries the content; title adds an optional aside --> <img src="map.png" alt="Office location: 4 King Street, two blocks north of Central station" title="Map updated March 2026"> ``` ## Why the delivery mechanism disqualifies `title` Browsers render `title` as a tooltip that appears after a mouse pointer rests over the element. Every part of that sentence is a barrier: - **Keyboard users** never produce a hover. Moving focus to an element does not show its tooltip. - **Touch users** have no hover state at all. On phones and tablets the tooltip generally never appears. - **Low-vision users** who magnify the screen may push the tooltip off the visible region, and the tooltip's styling is entirely browser-controlled — you cannot enlarge its text or fix its contrast. - **Anyone with a tremor or limited fine motor control** loses the tooltip the moment the pointer drifts. So the one group reliably served by `title` is sighted mouse users, who are also the group already looking at the image. ## Screen reader exposure is not something you can rely on Screen readers historically differ over whether they read `title`, when they read it, and whether they read it in addition to or instead of other text. Several expose a user setting for it, and some ship with it off by default because tooltip text is so often duplicated junk. The upshot: a string in `title` may be announced, announced twice, or silently ignored, and the author cannot tell which. Content whose delivery is a coin flip is not an alternative. There is a further trap. When an `<img>` has no `alt` at all, the browser may fall back to `title` when computing the image's name. That fallback is why teams observe title "working" on one machine and conclude it is interchangeable with alt. It is a repair path for broken markup, not a design. ## The failure modes you actually see 1. **`title` used instead of `alt`.** The image ends up with no defined alternative; validation flags the missing attribute, and behaviour depends on the reader's settings. 2. **`title` duplicating `alt` word for word.** Some combinations announce both, so the user hears the same sentence twice. If the string is worth saying, it belongs in `alt` alone. 3. **`title` holding essential instructions.** Anything a user must know to complete a task cannot live in a tooltip. Put it in visible page text. ## What to use instead of a tooltip If the extra information matters, make it visible content. A caption beneath the image, a line of help text, or a short paragraph is available to everyone and can be styled, translated and tested. When the visible text sits elsewhere in the page and you want it associated with the image programmatically, `aria-describedby` on the `<img>` pointing at that text's `id` is the mechanism — but visible text is the win, and the association is the refinement. The short version to say in an interview: `alt` is required content that replaces the image; `title` is optional decoration delivered by a mechanism that excludes keyboard, touch and many assistive-technology users. Write the alt.