In HTML, what does the title attribute on <abbr> provide, and why do accessibility practitioners warn against relying on it?
answer
- it is only the expansion
- hover is the delivery mechanism
- not focusable, no touch hover
- support varies, often off by default
- put it in the visible text
basics
~20 sIt supplies the abbreviation's expansion, which desktop browsers show as a hover tooltip. That reaches mouse users only: abbr cannot take focus, touch devices have no hover, and screen-reader handling of the attribute is inconsistent.
solid answer
~40 s`title` on `<abbr>` holds the expansion — `<abbr title="Cascading Style Sheets">CSS</abbr>` — and desktop browsers surface it as a hover tooltip. That is roughly the extent of its reach. `<abbr>` is not focusable, so a keyboard user can never trigger the tooltip; touch devices generally have no hover at all; and screen readers differ, with several ignoring the attribute by default and some reading the expansion instead of the abbreviation, which is not always what you want. The fix is not `tabindex`, which adds a tab stop to something with nothing to do. Expand the abbreviation in the visible text the first time it appears — "Cascading Style Sheets (CSS)" — and treat `title` as a convenience for mouse users rather than the mechanism anyone depends on.
code
html · 3 lines<p>We enforce a Content Security Policy
(<abbr title="Content Security Policy">CSP</abbr>) on every response.</p>
<p>Later mentions can use <abbr title="Content Security Policy">CSP</abbr> alone.</p>go deeper
Know that abbr marks an abbreviation and that title carries its expansion, and be able to write the element correctly with a real example.
Explain the delivery gaps precisely: hover-only tooltips, abbr not being focusable, no hover on touch, and screen-reader support that varies and is frequently off by default.
Demonstrate the production instinct — expand terms in the visible text on first use, refuse the tabindex workaround, and describe how you would audit a jargon-heavy page for terms readers cannot decode.
Own the content standard: decide where expansions live, whether a glossary is warranted, and how editorial tooling enforces first-use expansion so accessibility does not depend on a tooltip nobody can reach.
## What the element and the attribute mean `<abbr>` marks an abbreviation or acronym. `title` is a global attribute, but on `<abbr>` the spec gives it a specific job: when present, it must contain the expansion of the abbreviation and nothing else. ```html <p>The report is delivered as a <abbr title="Portable Network Graphics">PNG</abbr>.</p> ``` So far so reasonable — the meaning is recorded in the document. The trouble is entirely in delivery. ## Why the tooltip is a dead end The browser's tooltip appears on **hover**. Work through who that excludes: - **Keyboard users.** `<abbr>` is not an interactive element and is not in the tab order, so there is no way to focus it and no focus-triggered tooltip. The content is simply unreachable. - **Touch users.** Phones and tablets have no hover state. A long press may do nothing, or may trigger text selection instead. - **Zoom and low-vision users.** Native tooltips are rendered by the browser at a fixed size, cannot be styled, and may appear outside the magnified viewport. - **Anyone reading in a hurry.** A tooltip that appears after a delay, in a small font, off to the side, is a poor place for information the reader needs to understand the sentence. ## Screen reader behaviour is inconsistent There is no single answer to "what does a screen reader do with `<abbr title>`". Support has varied over the years and across products, and expansion announcement is commonly off by default or tied to a verbosity setting. Where it does fire, the behaviour is not uniform either: some configurations read the expansion **in place of** the abbreviation, so a user hears "Cascading Style Sheets" where the visible text says "CSS" — fine on first mention, tedious on the twentieth. Some read both. Some read neither. This is exactly the kind of claim to state carefully in an interview. "Support varies and is often off by default, so I do not design a page that depends on it" is a strong answer. "Screen readers read the title" is an overclaim an accessibility-minded interviewer will push back on. ## The pattern that actually works Put the expansion in the content, on first use, and keep the abbreviation afterwards: ```html <p>Every page ships a Content Security Policy (<abbr title="Content Security Policy">CSP</abbr>) header.</p> <p>Later in the article, plain <abbr title="Content Security Policy">CSP</abbr> is enough.</p> ``` Now every user — mouse, keyboard, touch, screen reader, print, translated copy — gets the expansion, because it is text. The `title` remains as a small convenience and as a machine-readable record; nothing depends on it. For a page thick with jargon, a visible glossary or an expandable definition that is a real interactive control beats a tooltip, because a real control is focusable, operable by keyboard, and announced with a role. ## The `tabindex` trap The tempting fix is `tabindex="0"` on the `<abbr>` so keyboard users can reach it. Resist it. It creates a tab stop on something that is not interactive: the user tabs to it, hears nothing useful, and cannot do anything there. You have added noise to the tab order without delivering the expansion. If the expansion deserves to be interactive, build an actual control with a real role and real keyboard behaviour rather than decorating a phrase-level element. ## Is `<abbr>` still worth using? Yes, for the semantic record and for tooling: it says "this token is an abbreviation", which is useful to translators, content pipelines, and readers of the source. Just decouple that from the question of how the expansion reaches users, which is answered by the visible text. ## Pitfalls worth naming Using `title` to hold something that is not the expansion (a definition, a joke, a link description) — on `<abbr>` the attribute has a defined meaning. Wrapping every occurrence of a term across a long page so a configured screen reader reads the full expansion dozens of times. Expecting the tooltip to be styleable — it is not. And, most common of all, treating `title` as an accessibility feature rather than as a mouse-only affordance.
- Would adding tabindex="0" to the <abbr> make the expansion accessible to keyboard users?No, and it makes things worse. It puts a tab stop on a non-interactive element, so a keyboard user lands somewhere with nothing to operate and still may not get the expansion. If the expansion genuinely needs interaction, build a real control with a role and keyboard behaviour; otherwise put the expansion in the visible text, where it costs nobody a tab stop.
- Is it worth using <abbr> at all if you already expand the term in the text?Yes, though it is optional. The element records that the token is an abbreviation, which helps translators, content tooling and anyone reading the source, and it costs nothing. What changes is that no user now depends on it: the expansion is delivered by the prose, and the markup is a semantic annotation rather than the mechanism.
- How would you handle a page that uses the same abbreviation forty times?Expand it once, on first use, and leave later mentions as the bare abbreviation. Repeating `title` on every occurrence risks a configured screen reader announcing the full expansion forty times, which is worse than saying nothing. For a jargon-heavy document, add a visible glossary and link to it rather than annotating every instance.
saying these in an interview costs you the question
- Says the title tooltip makes the page accessible
- Adds tabindex to abbr so the tooltip is reachable
- Assumes every screen reader reads title by default
- Puts a definition or link text in abbr's title
- Forgets touch devices have no hover state